Transporter (docs here) invoked via xcrun iTMSTransporter
, has a built-in auto-update mechanism. It will check for and cache new java libraries on first launch and once per day following, and always does this prior to actually invoking functionality.
You can verify this yourself by just running xcrun iTMSTransporter
and watching the log output, where you'll see the new library downloaded, i.e.:
[2021-12-18 10:27:17 EST] <ForkJoinPool.commonPool-worker-23> INFO: downloading resource: org.apache.logging.log4j.api/2.16.0
It will not replace the library in-place within the .app bundle, instead it will cache them to ~/Library/Caches/com.apple.amp.itmstransporter
and then only load the libs from that location. (You can also delete that cache directory to force it to re-run this process)
Given all of the above, it seems like there will be no cases of someone inadvertently using the vulnerable library, even though it would remain on disk in the Xcode app bundle, for as long as Apple continues shipping it (13.2.1 still includes it).
Since other platform companies and vendors have been able to quickly issue public statements on the subject of log4j2, I think the right thing for Apple's security or WWDR team to do would be to have a public KB article to just simply explain the above. Xcode is widely known and installed, log4j2 is now widely known, but these specific details are not. FB9811066 is my feedback/rdar asking for such a public KB/article on the subject.