Lots of "in collaboration with Claude and Anthropic Research" mentions, no mentions of other labs. I'd assume Apple already had access to whatever the most powerful model is at the various US-based labs, but perhaps not?
The gist is, OpenAI hired a high ranking Apple employee who helped other Apple employees get hired by OpenAI and exfiltrate Apple trade secrets in the process.
Do they? As in Claude but on premises? Wonder if this is gonna be the solution that e.g. banks will require, exactly like they do now for cloud services (e.g. Azure on premises).
Pretty extreme solution… you can get Claude models from AWS Bedrock and Google Model Zoo. These are both very helpful for compliance and security, but do require you to have a cloud strategy.
I don't believe it's published anywhere, but it's common knowledge to Apple engineers. I can second the poster's assertion that they run Claude internally.
I don’t know about hosting it internally but a an Apple focused podcast I listen to (Accidental Tech Podcast) has mentioned numerous times in the last few months they’re using Claude heavily. And they know Apple insiders.
Those were voluntary disclosures by two Anthropic researchers and the security firm Calif. I know one more CVE on the list that was discovered using an AI agent and wasn't disclosed as such. I suspect there are many more.
> Lots of "in collaboration with Claude and Anthropic Research" mentions
I wouldn't say 4 is lots. The entire list is massive. I haven't counted myself, but someone claimed that macOS 26.6 has the all-time record with 155 CVEs.
Considering that in Feb 2026 (https://support.apple.com/en-us/126348) Claude wasn't mentioned even once, 4 sure sounds like "lots" compared to nothing :) But you're right, it's subjective ultimately.
And it's not actually that much information "about the security content". For example: "Impact: An app may be able to access sensitive user data. Description: An access issue was addressed with additional sandbox restrictions." This references CVE-2026-43819, which doesn't have any more information. Compare this with the nearly decade-old https://support.apple.com/en-gb/103680, and you see much more specific information about problems and their remedies (except in situations where Apple's action was to update a vendor component).
The vagueness could be intentional. There’s been a big issue with linux where proof of concept exploit code gets posted before the bug is announced because people reverse engineer it from the fix commits.
Apple has the advantage that they can keep everything secret for long enough for the patches to roll out. And realistically there is no reason the user needs to know the details of an exploit that was patched before it was ever used.
It is a lot of fixes and the Android Security Bulletins of June and Android 17 also had a lot of fixes [1], despite ASBs only containing high/critical vulnerabilities (other vulnerabilities are only fixed in major releases and QPRs, which most Android vendors respectively roll out late or never at all).
I think the story here is that vulnerability discovery has accelerated a lot with LLMs, but since are adversaries are doing the same, it is more important than ever to update quickly (and not let some Android vendors get away with their lazy update schedules).
Right - it was always dangerous but people who figured they weren’t important enough to be attacked might find out that LLMs have shifted that cost in the wrong direction.
Collision counts are absurd. CVE-2026-43739 has roughly twenty credited researchers; CVE-2026-43816 has nearly as many. And ai attribution getting credit.
Map the amount of fixes with "... improved bounds checking...", "...improved memory handling...", "...improved memory management..." into the amount of developer, QA and release management teams salaries per hour, versus other stuff they could be working on, and that gives an approximate value of how using specific languages maps into monetary loss, and why companies are starting to care nowadays, given computers are always exposed to the world network.
>>, and that gives an approximate value of how using specific languages maps into monetary loss, and why companies are starting to care nowadays, given computers are always exposed to the world network.
You need also factor development time and ease of finding developers willing to work in a specific language. There are other factors like readability of the code (very verbose languages are likely to be worse) and cost of maintenance - languages forcing a lot of abstractions are likely much worse.
If you just meant apple-targeting developers, then yeah; you're right that those languages are in decline. But if you meant developers in general, I think you'd be surprised how many growth sectors are hiring C programmers. They're often not SaaS tech companies, but they are massive and many are growing. Hardware, industrial control systems, defense/aerospace ... there's a ton there, the spaces in which they hire just don't overlap a ton with the spaces frequented by hacker news. Also, a lot of them aren't US based companies.
I hope that changes over time, since I definitely agree that the downsides of C-family languages massively outweigh the downsides of competitor languages.
Which is why WG14 and WG21 caring about security would be quite relevant, but alas, priorities.
C could have gotten slices already in the 90's, the concept already existed in other languages, and even Dennis Ritchie made a fat pointer proposal into that sense.
The others, let see if anything related to profiles actually gets into C++29.
Citation needed. I don't think there's a correlation there. Over-architected Java spaghetti is verbose and unmaintainable. Under-architected Perl code golf that metastisized is terse and unmaintainable.
> languages forcing a lot of abstractions are likely much worse
Citation needed. C++ has had some very high-level abstractions on top of a low-level runtime for awhile, and plenty of people have decided to use it and hire for it regardless. What counts as an "abstraction" or "forced abstraction" is a very very subjective topic.
Even C can be super abstracted, see early 1980-90's business software written in C, with nice stuff like Yourdon Structured Method, leading to over-architected C spaghetti with macros, a decade before Java came to be.
The problem is the lack of interest since Morris worm came to be, to provide better mechanisms in said languages, until governments and key big tech names decided it was time to change existing practices.
It was my vague understanding that by the time you implemented all the apis needed to run normal software on top of that, you either have enough apis that different tasks can still compromise each other, or you have shoved everything into a single task with very little isolation between normal user processes. In either case, it doesn't seem like you actually gained so much. What am I missing?
For context, there have been issues with MacOS 26 which have led many people to defer upgrading until MacOS 27 is available, and MacOS 15 is the previous version.
Same thing happens almost every release. I've stopped updating my Mac machine until I see something in the release notes I literally have to have in order to continue doing macOS/iOS builds, otherwise I'm staying on the version I've validated to work, and I know the existing bugs with.
Yeah, I thought so too, but surprise surprise; some months ago one of the "minor" updates "broke" ("upgraded") something that made my CI/CD setup stop working, that's when I dropped the idea that Apple even do "minor" updates anymore.
Also a liquid glass hater, but for what it's worth, 27 is supposed to make it a little bit better. I would prefer to go back to what I had before I had to upgrade into this horrible UI, but this is better than nothing.
As long as the UI improves and I can ignore all the AI stuff they're starting to push through, that's fine with me, though like many longtime macOS users, I'm not holding my breath for a bug-free experience.
For those of us older than just 10 years of using macOS, the older Apple OSes have instilled within us the desire to never install the X.0 release and wait until at least the X.1 release. The bug-free experience is a myth
A couple of weeks ago, I had a Baltimore Oriole (a cool-looking bird, not a baseball player) in my yard. They aren't rare, per se, but they are uncommon.
Took my iPhone out to snap a picture, and pressed the camera button. I hadn't used it, since upgrading to 26.
It takes the picture. It's there. I can see it, but it won't let me save it. Instead, it wants to tell me about the cool new voice-activated AI retouch feature. There was no way to save.
I probably could have figured it out, but I was so furious, I just nuked the picture.
Also on the beta. Agreed. Definite visual and UX improvement over 26, fixing the most egregious issues with 26 implementation of Liquid Glass, but maybe not quite as good as 25 overall.
You can already turn off most glass effects in 26 via "System Settings => Accessibility => Display => Reduce Transparency".
I had that turned off years ago (for reasons I don't remember), and was wondering what all the fuzz was about when 26 came out because I didn't see much of a difference ;)
IMHO the actual important visual changes in the 27 beta is that rolls back the bizarre oversized corner radius in Finder windows, and they also got rid of the 'every menu item must have an icon' idea.
I've been running the 27 beta and it fixes so much of the ugliness I hated in Tahoe. Lots of places had toolbars restored, solid areas that indicate where the window can be grabbed. The shitty icon spam in menus is back to sanity. And window corner radii are consistent and less bulbous.
macOS 17 is decisively faster on my MacBook Air M1 16 GB than macOS 26/27 is on my MacBook Pro M2 Max 32 GB. And I don’t mean just the animations themselves but lag/sluggishness/responsiveness in general.
Same. It's not the worst thing in the world, at least with Reduce Transparency enabled in the Accessibility settings, but I still don't feel any inclination to upgrade. My personal Mac Studio is macOS 15 and my work MacBook is on macOS 26, and I don't think there's a single thing that I find to be better on the work laptop than on my personal machine.
I might update to macOS 26 in September to be ready to update to macOS 27. Being two versions behind doesn't seem reasonable and I'd rather be on the "Tahoe but less shitty" version than Tahoe itself.
Fortunately, those can run Linux. I recently installed Arch on an Intel T2. The only issue is that it does not have a TPM module, so the LUKS password needs to be manually entered at boot.
Love to see this, now if only they could revert the whole shimmering oil slick disaster that is "glass" on iOS (unlike macOS, even if I "reduce transparency", the oil slick effect still appears in many places, in addition to all the spacing issues).
I bought a MBP mainly for the hardware, otherwise I'd have stuck with Linux. OS-wise, the jump from Monterey (which I'd last used) to Sequoia was smooth and still feels that way. I prefer not to notice the OS at all, something that I feel would be hard to do on Tahoe due to all that liquid glass and dumb transparency and animations.
I found if you turn off transparency effects and turn on high contrast in the accessibility settings, it's actually a pretty nice looking UI. Still has some dumb quirks like inconsistent corner radiuses and text appearing under UI elements (because they're assumed to be transparent, but aren't). But all software is trash in 2026 so be thankful it isn't even worse, I guess.
Been doing that for years now already (performance boost). You can also do high contrast mode per app (if were talking about iOS). Must have for iMessage I think personally as it makes hard to read Green Bubbles a nice dark green that is very pleasant.
26.0 had a very annoying video jitter issue, but that was the first things that I noticed to be fixed in the next 26 release. Other than that, it worked just fine.
Did they un-hardcode the corner radius? I mean were they able to? I mean not that that anyone at this point needs convincing how utterly disgusting incompetent they’re at software.
I was shocked to find out the inconsistent corner radii in Tahoe was an intentional design decision. I figured it's so obviously bad that it was just sloppy work. But one of the WWDC session videos bafflingly clarified that it depends on whether the app has a toolbar or not.
I am fairly convinced this was all designed only in graphic tools, and looked nice in static mockups, like those fake desktops with overlapping small windows widely spaced, etc. The design folks probably all had giant studio displays with plenty of room, etc.
Then the reality of "what about toolbars", "what about dark mode", "what about laptop screens", etc were all afterthoughts and resulted in bolt-on fixes like that.
This may be a naive take, so if anyone has insight please feel free to share, but across Windows, Mac, and Linux OS's I see many cases of path parsing vulnerabilities resulting in sandbox escapes, code execution, or data access issues. When presenting the user with a file picker or command-line input, is it really needed that the software can handle the full POSIX spec?
I do not see a "typical" user needing to access a path with say a network storage but multiple ../.. and hard and soft symlinks simultaneously.
I think "be liberal in what you accept" might need to be revisited for path parsing with some sort of OS-wide single-implementation as an optional feature.
What I mean is that for “honest” software, built-in to the OS or otherwise, the programmer finds a situation where they take some user-supplied input and concatenate that into a path, and call something like OS.read(). If they want to prevent the user from causing havoc, they now find themselves dealing with path validation in their software instead of calling OS.safeOpen(), which would be a reduced subset of allowed chars?
Apropos, anyone else saw "fast user switching" in Tahoe turn into "excruciatingly slow user switching which after a minute of switching without success rebooted the whole damn machine"?
embedding-shape | 11 hours ago
tombot | 10 hours ago
muterad_murilax | 10 hours ago
fnord123 | 10 hours ago
mrtksn | 9 hours ago
Allegedly of course.
anonymars | 8 hours ago
https://news.ycombinator.com/item?id=48865294
makeitdouble | 8 hours ago
Jony Ive basically works for Open AI (it's more complicated, but it's a good approximation), and has more or less rebuilt a designing team over there.
He's not the central person mentioned in Apple's accusations but that's arguably the central point that's triggering all of this.
ajmurmann | 7 hours ago
danso | 6 hours ago
https://www.bbc.com/news/articles/cy8w379e091o
alwillis | 5 hours ago
He "took" several Apple employees with him when he left and there's been a steady stream of Apple employees going to OpenAI.
Ive isn’t responsible for all of them obviously, but the articles about lawsuits says there are 400 former Apple employees at OpenAI.
SoftTalker | 5 hours ago
manmal | an hour ago
MBCook | 3 hours ago
senadir | 10 hours ago
cromka | 10 hours ago
pbronez | 9 hours ago
UqWBcuFx6NV4r | 9 hours ago
ainch | 9 hours ago
cromka | 5 hours ago
Cider9986 | 9 hours ago
bel8 | 7 hours ago
edit: it seems asking for a source it frowned uppon in this site. And it seems there's no source.
mholm | 7 hours ago
MBCook | 7 hours ago
That would be a very Apple thing to do.
bel8 | 5 hours ago
And it seems nobody has a source so it's just humors as usual.
mholm | 5 hours ago
MBCook | 3 hours ago
alwillis | 5 hours ago
That's something Steve Jobs would have done.
MBCook | 7 hours ago
woadwarrior01 | 9 hours ago
lapcat | 8 hours ago
I wouldn't say 4 is lots. The entire list is massive. I haven't counted myself, but someone claimed that macOS 26.6 has the all-time record with 155 CVEs.
embedding-shape | 6 hours ago
claiir | 6 hours ago
AJRF | 11 hours ago
Are we wink winking that it's a lot of fixes?
croemer | 10 hours ago
DStiego | 10 hours ago
AI attribution might be one reason people are particularly curious.
AJRF | 8 hours ago
grahamlee | 10 hours ago
Gigachad | 7 hours ago
Apple has the advantage that they can keep everything secret for long enough for the patches to roll out. And realistically there is no reason the user needs to know the details of an exploit that was patched before it was ever used.
Tepix | 10 hours ago
cromka | 10 hours ago
nozzlegear | 6 hours ago
cromka | 5 hours ago
microtonal | 9 hours ago
I think the story here is that vulnerability discovery has accelerated a lot with LLMs, but since are adversaries are doing the same, it is more important than ever to update quickly (and not let some Android vendors get away with their lazy update schedules).
[1] https://source.android.com/docs/security/bulletin/2026/2026-... https://source.android.com/docs/security/bulletin/android-17
cubefox | 8 hours ago
acdha | 8 hours ago
cubefox | 2 hours ago
nizbit | 10 hours ago
croemer | 10 hours ago
CVE-2026-64691: Ruslan Dautov, Ruslan Dautov
proactivesvcs | 10 hours ago
CVE-2026-43744: Mathis Mansière, an anonymous researcher
nkrisc | 10 hours ago
receiptful-io | 10 hours ago
darkwater | 10 hours ago
rubslopes | 9 hours ago
conradfr | 9 hours ago
Someone | 9 hours ago
Not necessarily. Could be two persons sharing that name. See https://revstat.ine.pt/index.php/REVSTAT/article/view/382
ayewo | 59 minutes ago
pjmlp | 10 hours ago
bluecalm | 10 hours ago
You need also factor development time and ease of finding developers willing to work in a specific language. There are other factors like readability of the code (very verbose languages are likely to be worse) and cost of maintenance - languages forcing a lot of abstractions are likely much worse.
acdha | 8 hours ago
This even more strongly favors Rust or Swift. Nobody is writing C or even Objective-C in 2026 as a growth language.
zbentley | 7 hours ago
I hope that changes over time, since I definitely agree that the downsides of C-family languages massively outweigh the downsides of competitor languages.
pjmlp | 6 hours ago
C could have gotten slices already in the 90's, the concept already existed in other languages, and even Dennis Ritchie made a fat pointer proposal into that sense.
The others, let see if anything related to profiles actually gets into C++29.
zbentley | 7 hours ago
Citation needed. I don't think there's a correlation there. Over-architected Java spaghetti is verbose and unmaintainable. Under-architected Perl code golf that metastisized is terse and unmaintainable.
> languages forcing a lot of abstractions are likely much worse
Citation needed. C++ has had some very high-level abstractions on top of a low-level runtime for awhile, and plenty of people have decided to use it and hire for it regardless. What counts as an "abstraction" or "forced abstraction" is a very very subjective topic.
pjmlp | 6 hours ago
The problem is the lack of interest since Morris worm came to be, to provide better mechanisms in said languages, until governments and key big tech names decided it was time to change existing practices.
UqWBcuFx6NV4r | 9 hours ago
snvzz | 8 hours ago
pjmlp | 5 hours ago
yjftsjthsd-h | 5 hours ago
tengwar2 | 9 hours ago
For context, there have been issues with MacOS 26 which have led many people to defer upgrading until MacOS 27 is available, and MacOS 15 is the previous version.
embedding-shape | 8 hours ago
DavideNL | 6 hours ago
embedding-shape | 6 hours ago
Yeah, I thought so too, but surprise surprise; some months ago one of the "minor" updates "broke" ("upgraded") something that made my CI/CD setup stop working, that's when I dropped the idea that Apple even do "minor" updates anymore.
GeekyBear | an hour ago
jghn | 8 hours ago
For me the issue is liquid glass. Which I doubt is getting fixed any time soon
illithid0 | 8 hours ago
https://www.cultofmac.com/news/liquid-glass-changes-ios-27-m...
lapcat | 8 hours ago
Having installed the beta, I think that's the best you can say about it.
illithid0 | 8 hours ago
dylan604 | 6 hours ago
For those of us older than just 10 years of using macOS, the older Apple OSes have instilled within us the desire to never install the X.0 release and wait until at least the X.1 release. The bug-free experience is a myth
D-Coder | an hour ago
I think that applies to almost all software, not just Apple OSes. After all, Confucius said: "The only thing worse than old software is new software."
ChrisMarshallNY | 6 hours ago
iOS 26 anecdote:
A couple of weeks ago, I had a Baltimore Oriole (a cool-looking bird, not a baseball player) in my yard. They aren't rare, per se, but they are uncommon.
Took my iPhone out to snap a picture, and pressed the camera button. I hadn't used it, since upgrading to 26.
It takes the picture. It's there. I can see it, but it won't let me save it. Instead, it wants to tell me about the cool new voice-activated AI retouch feature. There was no way to save.
I probably could have figured it out, but I was so furious, I just nuked the picture.
Jolter | 8 hours ago
lapcat | 8 hours ago
Jolter | 5 hours ago
Tagbert | 7 hours ago
alwillis | 5 hours ago
etempleton | 8 hours ago
lapcat | 8 hours ago
Nothing will ever be as good as 25.
Because macOS 25 does not exist. ;-)
etempleton | 3 hours ago
trollbridge | 8 hours ago
flohofwoe | 8 hours ago
I had that turned off years ago (for reasons I don't remember), and was wondering what all the fuzz was about when 26 came out because I didn't see much of a difference ;)
IMHO the actual important visual changes in the 27 beta is that rolls back the bizarre oversized corner radius in Finder windows, and they also got rid of the 'every menu item must have an icon' idea.
trollbridge | 7 hours ago
SanjayMehta | 7 hours ago
trollbridge | 54 minutes ago
Melatonic | 2 hours ago
hbn | 7 hours ago
noname120 | 6 hours ago
classified | 6 hours ago
noname120 | 2 hours ago
iknowstuff | 5 hours ago
Hamuko | 7 hours ago
I might update to macOS 26 in September to be ready to update to macOS 27. Being two versions behind doesn't seem reasonable and I'd rather be on the "Tahoe but less shitty" version than Tahoe itself.
frizlab | 7 hours ago
reddalo | 7 hours ago
drnick1 | 4 hours ago
normie3000 | 2 hours ago
IdiotSavage | 7 hours ago
hbn | 7 hours ago
https://www.macrumors.com/2026/06/09/macos-golden-gate-liqui...
ak217 | 6 hours ago
simlevesque | 7 hours ago
pmdr | 6 hours ago
Seriously, who the heck even asked for those?
coldpie | 4 hours ago
Melatonic | 2 hours ago
shepherdjerred | 4 hours ago
ExoticPearTree | 8 hours ago
andreasley | 8 hours ago
carra | 8 hours ago
kylemaxwell | 8 hours ago
hbn | 7 hours ago
macOS went from 15 to 26
iOS went from 18 to 26
watchOS went from 11 to 26
and so on
classified | 6 hours ago
crossroadsguy | 7 hours ago
gedy | 7 hours ago
hbn | 7 hours ago
https://youtu.be/VqTn9NgiE1s?t=439
I can't imagine how the people who signed off on that were put in charge of design at Apple.
gedy | 5 hours ago
Then the reality of "what about toolbars", "what about dark mode", "what about laptop screens", etc were all afterthoughts and resulted in bolt-on fixes like that.
bouke | 7 hours ago
reddalo | 7 hours ago
Then there's me, crying in MacBook Pro 2019 stuck on MacOS 15 because 27 won't be available for my machine.
TheJoeMan | 6 hours ago
I do not see a "typical" user needing to access a path with say a network storage but multiple ../.. and hard and soft symlinks simultaneously. I think "be liberal in what you accept" might need to be revisited for path parsing with some sort of OS-wide single-implementation as an optional feature.
catlifeonmars | 6 hours ago
acuozzo | 6 hours ago
Typical users run software written by atypical users.
> some sort of OS-wide single-implementation
How do you propose handling migration? What if someone tries to expand an old archive file containing a now-forbidden path?
TheJoeMan | 5 hours ago
SoftTalker | 5 hours ago
If there's a path on the system that the user should not be able to read, that's the job of the OS to handle, not the individual applications.
FabHK | 5 hours ago
BoardsOfCanada | 4 hours ago