4 ms·

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 to

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 4mo 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 4mo ago
  Then why didn't they?
  - kimixa 4mo 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 4mo 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 4mo 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.
        tptacek 4mo 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.
        firesteelrain 4mo ago
        Black Duck products https://www.blackduck.com/fuzz-testing.html https://www.blackduck.com/fuzz-testing.html OpenText products https://www.opentext.com/products/dynamic-application-security-testing https://www.opentext.com/products/dynamic-application-securi... I won’t say how much they are here but they are very expensive.
        tptacek 4mo 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 4mo 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 4mo 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 4mo 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 4mo ago
  ... because it was vibe coded by someone in ... other country. Cut the corners, deliver fast! Consume tokens!

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 4mo 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 4mo ago
Then why didn't they?
- kimixa 4mo 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 4mo 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 4mo 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.
      - tptacek 4mo 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.
        firesteelrain 4mo ago
        Black Duck products https://www.blackduck.com/fuzz-testing.html https://www.blackduck.com/fuzz-testing.html OpenText products https://www.opentext.com/products/dynamic-application-security-testing https://www.opentext.com/products/dynamic-application-securi... I won’t say how much they are here but they are very expensive.
        tptacek 4mo 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 4mo 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 4mo 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 4mo 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 4mo ago
... because it was vibe coded by someone in ... other country. Cut the corners, deliver fast! Consume tokens!