Login
You're viewing the front-end.social public feed.

Replies

  • Nov 1, 2026, 12:49 AM

    @msw it's a weird correlation with php2shell, is CVE-2026-98432 actually being exploited in the wild or did it get a KEV just because anthropic produced an exploit chain? With enough effort, literally any security issue can be put into an exploit chain.

    💬 1🔄 0⭐ 0
  • Nov 1, 2026, 2:17 AM

    @siddhesh_p for PHP it is difficult to build a universal exploit, but there are some high value targets like Palo Alto firewalls with php based admin web interfaces exposed to the internet (don't do that!) where exploitation in the wild is reported (order of 30 deployed firewalls in that configuration reported).

    For this Linux IPv4 defect, no reported exploitation in the wild and no reported success outside of lab conditions at this time.

    💬 1🔄 0⭐ 0
  • Nov 1, 2026, 2:27 AM

    @msw yeah which is why I found the correlation odd. OP sounds more like "thought leader" marketing noise than any real insight. AC:H has a very specific meaning and has nothing to do with being able to write an exploit chain. If one cannot write an exploit chain with a vulnerability even in a lab environment then that's not a security issue at all.

    💬 2🔄 0⭐ 0
  • Nov 1, 2026, 2:29 AM

    @msw but I can understand folks considering this a KEV because that's the least worst thing to do under the circumstances. But it doesn't have to be this way, it's such a shame.

    💬 0🔄 0⭐ 0
  • Nov 1, 2026, 2:32 AM

    @siddhesh_p If the Palo Alto firewall exploit sightings came through credible channels, and the investigations were correct (Palo Alto confirmed this, fwiw), it's right to add CVE-2026-109618 and CVE-2026-109619 to the KEV.

    What I *don't* like about the KEV is that it doesn't give the most useful information to those who have the most meaningful exposure window: Palo Alto firewalls with their admin web interfaces exposed.

    It's PATCH ALL THE THINGS.

    💬 1🔄 0⭐ 0
  • 💬 1🔄 0⭐ 0
  • 💬 0🔄 0⭐ 0
  • Nov 1, 2026, 2:36 AM

    @siddhesh_p There are lots of defects that get CVEs where it is practically impossible to write a working exploit in known configurations of the software. They're given them CVEs anyway with descriptions like "this is most likely an availability risk but arbitrary code execution cannot be ruled out." Those often get high scores because C:H/I:H/A:H.

    💬 1🔄 0⭐ 0
  • Nov 1, 2026, 2:41 AM

    @msw we've had to deal with many of those in the glibc CNA; I suspect libraries experience this more than applications. To compensate, we try to explain the flaw in more detail so that distributions hopefully see that it's not an issue in practice.

    Although I doubt anybody reads anything beyond CVSS nowadays.

    💬 1🔄 0⭐ 0
  • Nov 1, 2026, 2:42 AM

    @siddhesh_p especially when a vulnerability starts trending on social media and across all the influencer blogs and cybersecurity feeds, few people are looking for the details at that point.

    They just want the patch, as fast as they can get it.

    💬 0🔄 0⭐ 0
  • Nov 4, 2026, 6:08 AM

    @msw CVSS has some pretty fundamental conceptual issues, which I’ve written about in the past[1]

    In theory you “should” be able to handle this through the temporal score component, but nobody does because people don’t have time, energy or inclination to think.

    Worse, it’s basically baked into stuff like SOC2, PCI-DSS, regulatory reviews etc etc. It might never die.

    Disclaimer: while I work for a bank these are just my own views.

    [1] theoryof.predictable.software/

    💬 0🔄 0⭐ 0