Live data from Hacker News

CVE-2026-28952: Apple macOS 26.5 Kernel Vuln found by Claude

support.apple.com

121–124 of 124 posts

Re: CVE-2026-28952: Apple macOS 26.5 Kernel Vuln found by Claude

#121

Earlier quoted context omitted.

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?

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.

Ah of course, thanks.

By the rest of the comment it looked like it was actually fine to share so this interpretation flew over my head.

Re: CVE-2026-28952: Apple macOS 26.5 Kernel Vuln found by Claude

#122
post #63
post #62

Earlier quoted context omitted.

A strong enough type system can catch permission problems.

The solution there would be a capabilities based OS, however adoption hasn't been great on that regard.

I'd love to see CHERI (for the room) and Wasm take off, no time like the present.

https://en.wikipedia.org/wiki/Capability_Hardware_Enhanced_R...

https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/

Re: CVE-2026-28952: Apple macOS 26.5 Kernel Vuln found by Claude

#123
post #89

Earlier quoted context omitted.

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?

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.

[flagged]

Re: CVE-2026-28952: Apple macOS 26.5 Kernel Vuln found by Claude

#124
post #96

Earlier quoted context omitted.

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.

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.

I find this amusing as Apple were the people I had direct interactions with that didn't run stuff like fuzzers or sanitizers as a matter of course - at least not in the situations I was involved with.

Though this was ~3 years ago now, and a lot of things have changed, but these tools were very much available and well known then - they aren't new. Though perhaps as they "knew" the project was coming to a close it wasn't a priority either?

It also might have fallen through the gaps due to the Apple internal/team culture - I worked for an external vendor, and we had to work against binary built framework dumps that didn't even allow us to enable things like address sanitizer completely either, and fuzzing difficult as you'd need to trace things through their opaque binary layers before it even reached our code.

Apple did have all our code though, it was very much an asymmetrical relationship, but if they were running such things as a matter of course in CI or similar you'd see that pattern in when they reported issues it caught, and the timings from time-of-bug-caused to time-of-report. It instead suggested any such runs were piecemeal and sporadic at best.

Though, it wouldn't really surprise me if they were being run and finding issues all the time, but they never actually got back to us. This certainly wouldn't be the first time we ran into "difficulties" due to the nature of the relationship and culture.

Post reply on HN