I wonder how well Apple has deployed these tools internally for security research.
Since mid-April Chrome showed 302 vulnerabilities patched, 225 of them found by Google. Same period last year was 19 vulnerabilities. They've also become more transparent recently, disclosing vulnerabilities found internally, not just externally (which Apple still doesn't appear to do). From the outside, it's hard to tell if Apple has deployed this tooling as much as Google.
guessmyname 1 days ago [-]
I am part of Apple's SEAR (Security Engineering and Architecture) organization and can’t attest that we have been using Anthropic models, including, but not limited to, Mythos, as part of our participation in Project Glassing and previous private partnerships with different frontier AI labs for years. We simply don’t talk about it because there’s no benefit to talk about it, and also NDA’s, but mostly because there’s no benefit to talk about it other than to satiate people’s curiosity about what we do or don’t do internally.
riffraff 1 days ago [-]
You wrote "can't attest" but the rest of what you wrote seems like you're actually attesting it.
Typo, or I am just misreading?
isomorphic 1 days ago [-]
The heavily ironic implication is that they're under NDA, so they can't attest to it, while more or less attesting it. Senator, I cannot confirm or deny that we definitely do this.
This could also be an unofficial-official way for Apple to "leak" that yes, they do this--which is on brand for how Apple handles "rumors" etc.
bitwize 1 days ago [-]
When the CIA representative says "I can neither confirm nor deny" it generally means the atrocities of which the agency has been accused did, in fact, take place.
MattPalmer1086 23 hours ago [-]
When I worked in the civil service we were trained to use that phrase to any query, no matter how innocuous (unless we had permission to give more info).
You may think that not issuing a categorical denial is suspicious, but generally speaking you cannot infer any information from that response. If it was only used when really bad things might have happened, maybe you could infer more.
qsxfthnkp2322 1 days ago [-]
Imagine working there with a boss who talks like this.
darig 1 days ago [-]
[dead]
19 hours ago [-]
lapcat 21 hours ago [-]
> there’s no benefit to talk about it
That there's no benefit to talking with the public is something that only Apple could believe.
Openness and honesty create trust. Secrecy creates distrust.
nprateem 1 days ago [-]
[flagged]
strictnein 1 days ago [-]
Person with an internal viewpoint gives their perspective and you decide the best response was to bite their head off. Wonderful.
pbgcp2026 1 days ago [-]
[flagged]
JCattheATM 1 days ago [-]
I'd guess they haven't even begun to really utilize them. They've never been a terribly security conscious company, despite the marketing.
krisbolton 1 days ago [-]
I think Apple became much better at security in recent years. One example which I think is indicative of their approach to security - they bothered to add a hardware microphone disconnect when a macbook is closed. Source: https://support.apple.com/en-gb/guide/security/secbbd20b00b/...
xyzzy123 1 days ago [-]
What's your thinking on this? From my perspective Apple security go pretty hard. They have a strong track record of being able to ship architectural mitigations like PACs / MIE / Exclaves first. I guess because Apple control the stack from silicon to userspace.
JCattheATM 1 days ago [-]
My thinking was in a historical context, and for their desktop OS's. I know they've been pretty on top of things with iPhones, and MacOS has become a lot better, but for the longest time MacOS was pretty lacking, coasting very much on promoting how much PCs have viruses and macs didn't, which was a marketshare thing more than a security thing. I don't think they got ASLR until later than pretty much everyone else, for example.
They've improved a lot, especially their phones, but I'd still never consider them a company that has a really strong focus on security.
dwaite 1 days ago [-]
Windows and macOS both got ASLR in 2007.
For another example: macOS integrated antivirus in 2009, while Windows did so in 2012.
JCattheATM 14 hours ago [-]
Apple's ASLR was incomplete and basically trash for a long time, it didn't get proper ASLR until much later.
pjmlp 21 hours ago [-]
I am PC, I am Mac campaign is from 2006, quite long time ago.
JCattheATM 14 hours ago [-]
Sure, I think I gave it that context by using the term historical.
xyzzy123 1 days ago [-]
Agree that pre Apple Silicon, macOS didn't get much focus. Fair point historically.
KennyBlanken 1 days ago [-]
That's a really strange claim given AS was a refinement of a technology other manufacturers have yet to surpass in the ten years since the T1 chip came out.
To this day nobody else ties their SMC, biometric auth, and HSM together as tightly and well as the T1 did. AS was further advancement of that.
Furthermore, Apple protects users against the legal changes that have allowed law enforcement to physically force someone to provide biometric credentials. By default MS just provides biometric auth to make it easier to log in to your system.
xyzzy123 1 days ago [-]
iOS always had a strong focus on security but if you take the time period say 2005 - 2015 it did not seem like there was much investment in macOS security at Apple. I am talking about stuff like exploit mitigations and relatively low hanging LPEs. Features like (full) ASLR / SIP / kext controls were added well after competitors.
KennyBlanken 1 days ago [-]
They were not "coasting" on anything. Everything about OS X has always been designed to protect users from the stuff Apple hasn't caught yet, because they know they can't always catch it first - and Apple has led the pack in nearly every major OS security feature of the last 25 years.
That includes "don't give the user root, and ask the user for their password before doing dangerous things" - four years before Linux distros started moving to a similar model.
jonhohle 1 days ago [-]
Didn’t Microsoft pioneer the privilege escalation prompts in Vista in 2007? It was a joke at the time how little things would hijack the entire screen to allow seemingly mundane things. I didn’t ever use Vista personally or professionally, but macOS has become pretty bad with basically the same model.
dwaite 1 days ago [-]
IMHO, both are a mode of progressively penalizing developers as a mode of API obsoletion. It doesn't feel like the opportunity to fix a degradation of user experience really motivated app developers in either case.
The difference is Apple is much more likely to progressively make these legacy feature compatibility more difficult for users to configure over time, and to remove them eventually.
kilpikaarna 1 days ago [-]
It was a joke mainly because of badly designed Windows apps being used to running as root in XP and earlier would ask for permissions _all_the_time_.
KennyBlanken 1 days ago [-]
MacOS X prompted users for their passwords in 2001.
Microsoft's implementation was (twenty years later still is) a joke because it prompted users to hit enter or click a button.
JCattheATM 1 days ago [-]
Microsoft's Secure Desktop feature is actually incredibly well designed, and provides strong protect against fraudulent prompts or prompt interception attacks.
pjmlp 21 hours ago [-]
Only if you configure it like that, you can make it ask for a password, and on more recent versions of Windows 11, optionally, a single use token.
Ironically Apple just recently added the same simpified approach.
NekkoDroid 20 hours ago [-]
> Only if you configure it like that
It is the default (unless they changed it in the last 2 years or so). I know for a fact that my PC and Laptop don't ask for my password and I know for a fact that I reinstalled Windows on my laptop less than 2 years ago and changed nothing regarding the UAC prompt (the closest that is even remotely close is enabling sudo in the settings).
pjmlp 19 hours ago [-]
May be, I never leave defaults on neither does our IT, so I might have that wrong.
curt15 14 hours ago [-]
> That includes "don't give the user root, and ask the user for their password before doing dangerous things" - four years before Linux distros started moving to a similar model.
Linux distros have always required sudo for "dangerous" things. What distros made users root by default?
JCattheATM 1 days ago [-]
> They were not "coasting" on anything.
Yeah, they were. Virus writers were not targeting them as a platform because why develop for 10% marketshare when you can target 90% for free. It just wasn't worth it to target as a platform. So there was some level of protection due to lack of interest in distributed attacks, but the OS had very little protection against targeted attacks.
> Apple has led the pack in nearly every major OS security feature of the last 25 years.
What an absurd claim. Apple trails behind, it never leads in this space. Windows 7 had numerous protections that had become standards that Apple still lacked when Windows 10 came out.
concinds 1 days ago [-]
> What an absurd claim. Apple trails behind
Recently there was an Anki vulnerability that gave any website access to any local files. On Windows or Linux this would be deadly. On macOS, Anki can't access my desktop or documents or Chrome storage or password manager storage. I think Apple's been smart about which security features it prioritizes.
AnthonyMouse 1 days ago [-]
> I guess because Apple control the stack from silicon to userspace.
People always say this but there is no real relationship there. When hardware vendors add security technologies to the hardware, the major third party operating systems add support to use it pretty much immediately, and in many cases before the hardware even ships because the hardware vendor publishes the documentation ahead of time.
Try to name something where Apple was the first to support something (by a non-trivial amount of time) not because they were the first to add hardware support but because they released the combination of hardware and software in the time between when e.g. Intel or Qualcomm added hardware support and when Linux or Windows added software support to use it.
Aurornis 1 days ago [-]
More than 26.5:
> The affected releases include iOS 18.7.9 and iPadOS 18.7.9, macOS Sequoia 15.7.7, macOS Sonoma 14.8.7, and macOS Tahoe 26.5.
I’ve already seen a lot of people self-congratulating for not updating to Tahoe but this isn’t exclusive to Tahoe.
tom_ 1 days ago [-]
> The affected releases include iOS 18.7.9 and iPadOS 18.7.9, macOS Sequoia 15.7.7, macOS Sonoma 14.8.7, and macOS Tahoe 26.5.
Where does this quote come from? I can't see it in https://support.apple.com/en-us/127115, the article link at time of writing. It mentions CVE-2026-28952, but we're forced to guess why. I'd take the reference to mean that this issue is fixed, but I'm just some internet rando, so what the hell do I know?
If I do a google search for "CVE-2026-28952", it points me to various pages. Here's one, for example: https://www.cve.org/CVERecord?id=CVE-2026-28952 - which is a bit more explicit, though of course this is not from the horse's mouth:
> This issue is fixed in iOS 18.7.9 and iPadOS 18.7.9, macOS Sequoia 15.7.7, macOS Sonoma 14.8.7, macOS Tahoe 26.5
dragonsenseiguy 1 days ago [-]
Ah thanks! I was only looking at Tahoe since my mac had an update and I usually look at the security release notes.
maximilianburke 1 days ago [-]
I haven't been able to update my iPhone in months because it just does not have enough room available to download the update. I just checked now and it needs 13.2 GB free to be able to update to iOS 26.5 (from 26.3). On a 64gb device!
It just seems like massive software development malpractice to tie together critical operating system updates with whatever else they've bundled.
jonhohle 1 days ago [-]
You can do a tethered update and get a local backup at the same time.
ttkari 1 days ago [-]
I have a 32 GB iPad, I think it's the year 2020 model. The OS alone uses 19 GB ("iPadOS" 12.3 GB + "System Data" 6.4 GB) so yeah, not much chance doing any OTA updates on that one with the requirement of 13+ GB free.
Maybe some day the fruit company with all their billions will be able to innovate a solution for deploying for example browser fixes so that they can be installed without requiring tens of gigabytes of free storage on the device. Meanwhile, we're stuck using a computer and iTunes for that.
zx8080 1 days ago [-]
I thought one just get a new iphone when run out of storage.
Alifatisk 1 days ago [-]
That’s insanity
greatgib 1 days ago [-]
Exactly what you need to buy and use apple products...
dyauspitr 1 days ago [-]
It’s insane. It’s always an ordeal. They put so little storage on these phones that 20% of it is for iOS/system already. On top of that requiring 13-15 GB for an update is a huge pain.
fosterfriends 1 days ago [-]
Kernel
Available for: macOS Tahoe
Impact: An app may be able to cause unexpected system termination
Description: An integer overflow was addressed with improved input validation.
CVE-2026-28952: Calif.io in collaboration with Claude and Anthropic Research
ZPrimed 1 days ago [-]
This isn't a 26.5 bug, this is a bug fixed in 26.5.
dragonsenseiguy 1 days ago [-]
Ah my bad for the wrong wording.
awestroke 1 days ago [-]
But it's a 26 (Tahoe) bug. Earlier OS versions unaffected
dwaite 1 days ago [-]
> This issue is fixed in iOS 18.7.9 and iPadOS 18.7.9, macOS Sequoia 15.7.7, macOS Sonoma 14.8.7, macOS Tahoe 26.5
For many years my go-to plan has been to stay one point release behind apple's releases, especially the .0 releases -- but, times change. Last night I pushed the button for 26.5, thinking about the Glasswing/Mythos reporting. Seems like staying on bleeding edge is going to be the name of the game.
I wonder if this will change general dynamics -- feels like LTS releases could become even more important, at the same time having reduced maintenance costs since you can have some agentic help on backporting.
mort96 1 days ago [-]
Staying one point release behind is weird isn’t it? I get staying a major release behind, Apple’s x.0 releases are often pretty rough so it might be worth staying on x-1 for a while. But point releases mostly just fix the stuff they broke in the major release.. Would you really upgrade from 18.5 or whatever to 26.0 when Apple releases 26.1?
Marsymars 1 days ago [-]
Point releases for macOS can be pretty large over the past several years - what often makes sense is waiting a few weeks to upgrade in case there's a .1 patch.
e.g. macOS 15.0, 15.1, 15.3, 15.4, 15.6 and 15.7 all had .1 patches within a few weeks of release.
samtheprogram 1 days ago [-]
Security updates still go out for older major releases back 2 versions. You didn’t need to jump to 26 if you weren’t on it.
baq 1 days ago [-]
Tell that to my IT department please
1 days ago [-]
dragonsenseiguy 1 days ago [-]
Same! I almost never updated, now I feel like i need to update. Kinda feels like FOMO but for security updates
three_burgers 1 days ago [-]
CVE-2026-28952 is about an integer overflow due to lack of input validation. I wonder what makes such vulnerability difficult to discover by traditional SAST tools?
firesteelrain 1 days ago [-]
Fuzzing, dynamic analysis or DAST might have found it too.
Assuming Apple has deployed all of these and have invested in the labor/training on how to properly use them.
tptacek 1 days ago [-]
Then why didn't they?
kimixa 1 days ago [-]
I think the real point is they didn't - until it became a "marketing" thing for another company who did it for them.
A lot of these issues would be highlighted by "legacy" (pre-AI) analysis tools. The issue is that they weren't being run.
tptacek 20 hours ago [-]
Why not? We're talking about vulnerabilities with real market value here. If it was just a tool run, why weren't the tools run?
Isn't the simpler explanation that they weren't just a tool run?
firesteelrain 20 hours ago [-]
The tools are expensive. One of the major players in the market have really expensive licensing fees. Then the developers all need to be trained on how to use the tools and understand the results. It’s not something they teach effectively in schools.
Software engineering is still kind of new overall.
akerl_ 17 hours ago [-]
Apple has a massive information security organization that has pretty intense resources at their disposal.
It seems borderline impossible that there's a tool that they feel would be beneficial but that they're classed out of using by license costs or by staff proficiency.
firesteelrain 17 hours ago [-]
It happens at a lot of places that the budget isn’t unlimited when it comes to information security. But even then it comes down to risk management.
akerl_ 11 hours ago [-]
We’re in a thread about an Apple vulnerability, where the claim was made that they’d have found these if they’d properly run traditional tooling.
tptacek 18 hours ago [-]
Which tool specifically are you thinking of that might have found this but wasn't run because of it's very high licensing fees? I work in this field, I'll be familiar with it.
I won’t say how much they are here but they are very expensive.
tptacek 16 hours ago [-]
Just to be clear: your claim is that the Black Duck fuzzer would have enabled the rapid discovery of kernel vulnerabilities in macOS?
firesteelrain 15 hours ago [-]
Question was about high licensing fees and which tools I was referring to
I’m not claiming Defensics or OpenText DAST tools are magical “find all kernel vulns” buttons
My point is more that mature fuzzing ecosystems already existed before the recent AI-driven approaches. Protocol fuzzers, syscall fuzzers, coverage-guided fuzzers, sanitizers, dynamic analysis, etc. have all historically found serious kernel bugs
tptacek 15 hours ago [-]
We might just be talking past each other. My question, from upthread, is this: the heyday of AFL was over a decade ago. Every major platform company fuzzes at a scale that I think is difficult for lay practitioners to get their heads around. They contract, quarterly, soup-to-nuts assessments from competing software security companies, who get full source access and are measured against each other by the quality of their findings. They run bounty programs specifically to direct public researcher attention to these exact findings.
Why didn't "mature fuzzing ecosystems" find the vulnerabilities AI is now finding? It's a pretty big gap in the "fuzzing tools already do this" logic!
Someone 19 hours ago [-]
Could be any (combination) of
- looking at components in isolation, not realizing that a component could receive untrusted input
- looking at the entire system, but not in a configuration that made the CVE possible
- having to be extremely lucky to find the issue through fuzzing, and Apple not hitting that jackpot
- having found the issue in testing, but incompletely/incorrectly fixing it
- mostly focusing testing on other components because this one’s code didn’t change and hadn’t seen issues in years
I don’t think we have enough info to know which (or something entirely different) it is.
pbgcp2026 1 days ago [-]
... because it was vibe coded by someone in ... other country. Cut the corners, deliver fast! Consume tokens!
Gigachad 1 days ago [-]
It's funny how in the past a server uptime used to be a kind of badge of honor, while now a computer running for more than a week is a massive security risk.
I've had to be on top of updating everything constantly lately.
fl1pper 1 days ago [-]
Where all of this is going? Will there be a dedicated servers running coding agents that iterate throught codebases for each company to find vulnerabilities 24/7?
openai announced aardvark last year, no they call it codex security.
Aurornis 1 days ago [-]
More like: There will be a budget for tokens to be spent on security audits.
1000 different companies will be pitching your CTO their proprietary vulnerability scanning harness as the most cost effective.
colejohnson66 1 days ago [-]
So what already happens, but worse?
flomo 1 days ago [-]
It's just another tool in the belt. Someone will say that's cheaper than rewriting in safe rust or whatever. (Apple must have a bunch of 1980s code written to 1980s standards. But that is their moneymaker.)
pjmlp 21 hours ago [-]
Yes, this is quite similar to proper configured CI/CD pipelines, which unfortunely are still a minority across the industry.
vessenes 1 days ago [-]
Yes
jeffbee 1 days ago [-]
Why shouldn't there be such things? We already have fuzzing, and responsible software publishers dedicate 24/7 resources to fuzzing.
embedding-shape 1 days ago [-]
Claude and Anthropic is mentioned, but not Mythos, I'm guessing this would mean then this was found outside of the whole Mythos thing, or would there be any reason for them not to mention it, if it was involved?
sigmar 1 days ago [-]
It was Mythos
>Our engineers, working together with Mythos Preview, built a working exploit in five days.
Sidenote but: it's crazy how big this update is. 13 GB is crazy
jshier 1 days ago [-]
Update from 26.3 to 26.4 for the Studio Display XDR was 2.4GB. And that's for a variant of iOS designed for screens.
atonse 1 days ago [-]
Yeah I’m honestly not sure why macOS updates seem to be so huge. Often gigabytes. Do they actually have thousands of changes, so they basically ship out new versions of almost all system libraries? Or is it that they don’t have good diffing in place? Or is it a BSD thing where you basically ship everyone at once since it’s all sort of “one version” of the base system?
alwillis 1 days ago [-]
> Yeah I’m honestly not sure why macOS updates seem to be so huge.
An update to macOS 26.5 contains all the necessary code to update a Mac from 26.0 to 26.5 for both x86_64 and arm64 architectures.
atonse 17 hours ago [-]
But aren't they able to do incremental builds and separated x64/arm64?
They know which OS version is requesting an update, at least the version number part.
alwillis 17 hours ago [-]
> But aren't they able to do incremental builds and separated x64/arm64?
During the PowerPC to Intel transition, they did stuff like that; perhaps at their current scale, there's reasons why they don't.
Supporting both architectures enables a macOS install to boot an Intel Mac or an Apple Silicon Mac, which is useful in a dual-architecture environment.
It's easy to check for dual architecture support; just use the file command:
when multiple independent parties are simultaneously tripping over different holes in the same kernel, that's not bad luck, that's a systemic attack surface problem
pjmlp 1 days ago [-]
Which gets even better by still using C.
Large majority of CVEs in the update are related to memory corruption, out of bounds and use after free.
Naturally the logic and wrong permissions ones would happen regardless of the language.
sitkack 1 days ago [-]
A strong enough type system can catch permission problems.
pjmlp 1 days ago [-]
The solution there would be a capabilities based OS, however adoption hasn't been great on that regard.
For the record, this bug has nothing to do with our recent MIE attack [1] [2], which exploited two different kernel bugs. Our bugs are not fixed yet.
[1] https://blog.calif.io/p/first-public-kernel-memory-corruptio...
[2] https://news.ycombinator.com/item?id=48139219
vulnerabilities have already been fixed, and the system update was pushed 2026/05/11 †
> This document describes the security content of macOS Tahoe 26.5.
think: this is what we included with the tahoe 26.5 update 2 weeks ago
thanks ZPrimed (https://news.ycombinator.com/item?id=48273889)
† https://support.apple.com/en-us/122868
Since mid-April Chrome showed 302 vulnerabilities patched, 225 of them found by Google. Same period last year was 19 vulnerabilities. They've also become more transparent recently, disclosing vulnerabilities found internally, not just externally (which Apple still doesn't appear to do). From the outside, it's hard to tell if Apple has deployed this tooling as much as Google.
Typo, or I am just misreading?
This could also be an unofficial-official way for Apple to "leak" that yes, they do this--which is on brand for how Apple handles "rumors" etc.
You may think that not issuing a categorical denial is suspicious, but generally speaking you cannot infer any information from that response. If it was only used when really bad things might have happened, maybe you could infer more.
That there's no benefit to talking with the public is something that only Apple could believe.
Openness and honesty create trust. Secrecy creates distrust.
They've improved a lot, especially their phones, but I'd still never consider them a company that has a really strong focus on security.
For another example: macOS integrated antivirus in 2009, while Windows did so in 2012.
To this day nobody else ties their SMC, biometric auth, and HSM together as tightly and well as the T1 did. AS was further advancement of that.
Furthermore, Apple protects users against the legal changes that have allowed law enforcement to physically force someone to provide biometric credentials. By default MS just provides biometric auth to make it easier to log in to your system.
That includes "don't give the user root, and ask the user for their password before doing dangerous things" - four years before Linux distros started moving to a similar model.
The difference is Apple is much more likely to progressively make these legacy feature compatibility more difficult for users to configure over time, and to remove them eventually.
Microsoft's implementation was (twenty years later still is) a joke because it prompted users to hit enter or click a button.
Ironically Apple just recently added the same simpified approach.
It is the default (unless they changed it in the last 2 years or so). I know for a fact that my PC and Laptop don't ask for my password and I know for a fact that I reinstalled Windows on my laptop less than 2 years ago and changed nothing regarding the UAC prompt (the closest that is even remotely close is enabling sudo in the settings).
Linux distros have always required sudo for "dangerous" things. What distros made users root by default?
Yeah, they were. Virus writers were not targeting them as a platform because why develop for 10% marketshare when you can target 90% for free. It just wasn't worth it to target as a platform. So there was some level of protection due to lack of interest in distributed attacks, but the OS had very little protection against targeted attacks.
> Apple has led the pack in nearly every major OS security feature of the last 25 years.
What an absurd claim. Apple trails behind, it never leads in this space. Windows 7 had numerous protections that had become standards that Apple still lacked when Windows 10 came out.
Recently there was an Anki vulnerability that gave any website access to any local files. On Windows or Linux this would be deadly. On macOS, Anki can't access my desktop or documents or Chrome storage or password manager storage. I think Apple's been smart about which security features it prioritizes.
People always say this but there is no real relationship there. When hardware vendors add security technologies to the hardware, the major third party operating systems add support to use it pretty much immediately, and in many cases before the hardware even ships because the hardware vendor publishes the documentation ahead of time.
Try to name something where Apple was the first to support something (by a non-trivial amount of time) not because they were the first to add hardware support but because they released the combination of hardware and software in the time between when e.g. Intel or Qualcomm added hardware support and when Linux or Windows added software support to use it.
> The affected releases include iOS 18.7.9 and iPadOS 18.7.9, macOS Sequoia 15.7.7, macOS Sonoma 14.8.7, and macOS Tahoe 26.5.
I’ve already seen a lot of people self-congratulating for not updating to Tahoe but this isn’t exclusive to Tahoe.
Where does this quote come from? I can't see it in https://support.apple.com/en-us/127115, the article link at time of writing. It mentions CVE-2026-28952, but we're forced to guess why. I'd take the reference to mean that this issue is fixed, but I'm just some internet rando, so what the hell do I know?
If I do a google search for "CVE-2026-28952", it points me to various pages. Here's one, for example: https://www.cve.org/CVERecord?id=CVE-2026-28952 - which is a bit more explicit, though of course this is not from the horse's mouth:
> This issue is fixed in iOS 18.7.9 and iPadOS 18.7.9, macOS Sequoia 15.7.7, macOS Sonoma 14.8.7, macOS Tahoe 26.5
It just seems like massive software development malpractice to tie together critical operating system updates with whatever else they've bundled.
Maybe some day the fruit company with all their billions will be able to innovate a solution for deploying for example browser fixes so that they can be installed without requiring tens of gigabytes of free storage on the device. Meanwhile, we're stuck using a computer and iTunes for that.
Impact: An app may be able to cause unexpected system termination
Description: An integer overflow was addressed with improved input validation.
CVE-2026-28952: Calif.io in collaboration with Claude and Anthropic Research
* https://nvd.nist.gov/vuln/detail/CVE-2026-28952
* https://nvd.nist.gov/vuln/detail/CVE-2026-28942
I wonder if this will change general dynamics -- feels like LTS releases could become even more important, at the same time having reduced maintenance costs since you can have some agentic help on backporting.
e.g. macOS 15.0, 15.1, 15.3, 15.4, 15.6 and 15.7 all had .1 patches within a few weeks of release.
Assuming Apple has deployed all of these and have invested in the labor/training on how to properly use them.
A lot of these issues would be highlighted by "legacy" (pre-AI) analysis tools. The issue is that they weren't being run.
Isn't the simpler explanation that they weren't just a tool run?
Software engineering is still kind of new overall.
It seems borderline impossible that there's a tool that they feel would be beneficial but that they're classed out of using by license costs or by staff proficiency.
https://www.blackduck.com/fuzz-testing.html
OpenText products
https://www.opentext.com/products/dynamic-application-securi...
I won’t say how much they are here but they are very expensive.
I’m not claiming Defensics or OpenText DAST tools are magical “find all kernel vulns” buttons
My point is more that mature fuzzing ecosystems already existed before the recent AI-driven approaches. Protocol fuzzers, syscall fuzzers, coverage-guided fuzzers, sanitizers, dynamic analysis, etc. have all historically found serious kernel bugs
Why didn't "mature fuzzing ecosystems" find the vulnerabilities AI is now finding? It's a pretty big gap in the "fuzzing tools already do this" logic!
- looking at components in isolation, not realizing that a component could receive untrusted input
- looking at the entire system, but not in a configuration that made the CVE possible
- having to be extremely lucky to find the issue through fuzzing, and Apple not hitting that jackpot
- having found the issue in testing, but incompletely/incorrectly fixing it
- mostly focusing testing on other components because this one’s code didn’t change and hadn’t seen issues in years
I don’t think we have enough info to know which (or something entirely different) it is.
I've had to be on top of updating everything constantly lately.
google has been running ClusterFuzz since ~2012, and naptime was announced in 2024 (https://projectzero.google/2024/06/project-naptime.html). they call it big sleep and codemender now.
openai announced aardvark last year, no they call it codex security.
1000 different companies will be pitching your CTO their proprietary vulnerability scanning harness as the most cost effective.
>Our engineers, working together with Mythos Preview, built a working exploit in five days.
https://news.ycombinator.com/item?id=48139219
An update to macOS 26.5 contains all the necessary code to update a Mac from 26.0 to 26.5 for both x86_64 and arm64 architectures.
They know which OS version is requesting an update, at least the version number part.
During the PowerPC to Intel transition, they did stuff like that; perhaps at their current scale, there's reasons why they don't.
Supporting both architectures enables a macOS install to boot an Intel Mac or an Apple Silicon Mac, which is useful in a dual-architecture environment.
It's easy to check for dual architecture support; just use the file command:
Large majority of CVEs in the update are related to memory corruption, out of bounds and use after free.
Naturally the logic and wrong permissions ones would happen regardless of the language.
https://app.opencve.io/cve/CVE-2026-28952
Sequoia also has security bugs :) https://support.apple.com/en-us/127116