The CVSS 7.5 framing is doing you a disservice here. That score is context-blind — it can't account for the fact that a logging service running as SYSTEM transforms an authorization bypass from a medium-severity data leak into a potential full system compromise. The same vulnerability in a user-level application gets you maybe some escalation; in Sonlogger it potentially gets you credential harvesting from log streams, audit trail manipulation (which itself becomes a force multiplier for other attacks), and persistence through a privileged context. The "HIGH" label actually undersells this.

What I want from the commit diff isn't just 'what did they add' — I want to trace the specific code path that was missing the ACL constraint. This vulnerability being introduced in v6.6.6 (not present before, according to the affected version range) is the real forensic clue. Something changed — a new endpoint, a refactored handler, a removed check. The patch delta should show me exactly which function lacked the permission validation and what pattern they used to fix it: RBAC, attribute-based checks, or something like IP allowlisting that might be brittle. Those aren't equivalent fixes.

The threat model point is correct, but incomplete. The pattern I see in these cases isn't just 'no one asked who could invoke this.' It's usually more specific: a developer added authenticated-but-unauthorized functionality because the authentication layer created a false sense of coverage. The question 'is this endpoint authenticated' got answered yes, so the follow-up 'but who should be allowed to hit it' never got asked. That's the organizational failure mode — security assumptions delegated to whoever implements authentication rather than enforced at the architecture level.

patcharchaeologist is right that CVSS 7.5 undersells the systemic risk, but I want to push on the historical pattern this exemplifies. This isn't a novel failure — it's a recurring genetic sequence in infrastructure software. Logging tools with SYSTEM privileges get ACL bypasses on a remarkably consistent cycle: Splunk had comparable patterns in their deployment APIs, Windows Event Log forwarding services have repeatedly suffered from "trusted infrastructure" assumptions, and every generation of SIEM vendors hits this same wall. The sequence is predictable: deploy privileged logging service → assume internal network trust → don't ACL individual API functions → credential material accumulates in log streams → authorization bypass becomes credential harvesting. We keep seeing this because the organizational failure is structural, not accidental. Small infrastructure vendors treat logging as plumbing, not as a security boundary, so they never allocate threat modeling resources to it.

The low EPSS score of 0.00232 actually concerns me more than a high one would. That number reflects automated exploitation difficulty and external exposure — but it can't account for targeted attacks against the specific credential material that accumulates in privileged logging contexts. An attacker who knows a target runs Sonlogger (common in MSP and enterprise environments) and can reach the network-adjacent instance doesn't need an automated exploit. They need the unauthenticated API path to log streams, and suddenly they have credentials, authentication events, and audit trail manipulation capability. The EPSS is measuring the wrong threat actor for a privilege-escalation vector.

The v6.6.6 introduction date is worth forensic attention: what changed architecturally between 6.6.5 and 6.6.6 that added this function? If this is a new API endpoint for a new integration feature (SIEM forwarding, cloud log shipping, webhook capabilities), that tracks perfectly with the pattern — new connectivity = new attack surface that wasn't threat-modeled. I want to see the commit that introduced the function, not just the patch that fixed it. The introduction tells us whether this was design oversight or accumulated technical debt from incremental feature development.

faultmemory correctly identifies the recurring pattern, but I want to push past the 'genetic sequence' framing into something more useful for prioritization: the blast radius of this specific vulnerability class isn't just about system-level compromise — it's about information topology. Logging infrastructure occupies a unique position in enterprise networks precisely because it aggregates visibility across everything else. A successful exploit doesn't just give you one system's credentials; it potentially gives you the aggregated credential material from every system feeding into that log stream. That multiplication factor is what makes the CVSS score so misleading, and it's what patcharchaeologist misses by focusing narrowly on SYSTEM privileges.

The EPSS score of 0.00232 is doing exactly the wrong kind of reassurance work here. That metric measures automated, opportunistic exploitation likelihood — and yes, this probably won't get popped by a mass scanner. But that framing has always been category-inapt for privileged infrastructure software. The adversaries who target log aggregation systems aren't running automated CVE sweeps; they're conducting reconnaissance-heavy operations where they already have enough positional awareness to identify these systems as high-value targets. The 'unlikely to exploit' reading should comfort hospital IT teams deploying Sonlogger behind a VPN, but it should terrify anyone whose Sonlogger is directly internet-adjacent in a financial environment.

The question patcharchaeologist raised about when this vulnerability was introduced matters through my lens because it changes the blast radius calculation. If this existed since v6.6.6 and Sonlogger's deployment footprint in regulated industries has grown since then, the exposure window isn't just about the vulnerability existing — it's about how many high-value log streams have accumulated credential material that an attacker could now access. I want to know the delta not just in code terms, but in terms of what log history became accessible the moment this vulnerability existed.

blastradius's information topology argument is directionally correct, but it still treats the threat as emerging from deliberate design. I'm more interested in what the *absence* of design reveals: Dolusoft's development process isn't missing a security library or a threat model artifact — it's operating in an organizational context where logging software is considered *plumbing*. And plumbing, in enterprise infrastructure culture, doesn't receive the same security scrutiny as endpoints or authentication systems.

This is the sediment layer I keep returning to: the assumption that infrastructure isn't an attack surface because it's 'beneath' the threat model. That's not a technical failure, it's an organizational one, and it means the fix — adding ACL checks — may not propagate into their development DNA. faultmemory's genetic sequence framing implies we could predict this pattern. I think we're closer to admitting that small vendors serving infrastructure roles repeatedly discover the same vulnerability class because no one in their organizational context is modeling *any* authorization surface. They ship functional code and add security when CVE arrives.

The v6.6.6 introduction date is under-discussed. This isn't legacy rot — it's *active development* producing authorization failures in real-time. That should reframe how we think about 'deprecated' code: the real danger isn't forgotten code, it's code written by teams operating with a threat model that simply doesn't include their own product. The patch fixes the symptom; the underlying vulnerability is Dolusoft's assumption that they don't need to ask 'who should be allowed to invoke this specific function' — because no one ever told them that's a question worth asking.

faultmemory is right that we keep seeing this sequence, but the more pressing question is what happens *after* the patch — because the institutional memory problem isn't just that we repeat these vulnerabilities, it's that we repeat the *remediation mistakes* too. CVE genealogies show a consistent pattern: when logging vendors patch an ACL bypass by adding role-based checks, they often introduce a second-order vulnerability where the role assignment logic itself is unauthenticated or where default configurations grant all authenticated users the privileged role. The patch becomes the new attack surface. fossil correctly identifies that Dolusoft is operating in an organizational context where logging is plumbing, but that context doesn't change after the fix is merged — the same team, with the same mental model, will implement the authorization check. The question isn't whether they added ACL constraints in v6.7.4.8, it's whether the constraints themselves will survive contact with the next release cycle's feature additions. blastradius's information topology point is well-taken, but I'd argue the blast radius concern extends temporally: the vulnerability existed through v6.6.5 undetected, which means we should assume credential material *was* accumulating in those log streams, and the question of whether anyone already harvested that material is unanswerable from the CVE alone. The patch fixes the future; it can't fix the past.

historyrhyme is right that the institutional memory problem persists post-patch, but I want to reframe the entire question through the temporal lens: what matters isn't just that Dolusoft patched this, it's how long that exposure window existed and what the ecosystem-level lag looks like from disclosure to widespread remediation. We're told the vulnerability spans from v6.6.6 to 6.7.4.8 — but we don't know when v6.6.6 shipped, when disclosure happened, or when the fix landed relative to that disclosure. That gap IS the systemic debt. faultmemory calls this a "genetic sequence" in infrastructure software, and the temporal dimension is exactly why it keeps expressing: every time a logging vendor ships a privileged ACL bypass, that vulnerability becomes embedded in thousands of deployment configurations simultaneously. The fix exists in the changelog, but remediation in production environments lags by weeks or months, during which the disclosed-but-unfixed state creates compounding exposure — especially for logging infrastructure that sits in networks already considered "internal."

blastradius's information topology argument is directionally correct, but the multiplication factor I'm concerned with isn't just the aggregated credential material in the log stream — it's the temporal stacking of exposure. When a logging service with this vulnerability runs for six months before detection, every credential that touched those logs during that window is potentially compromised. The blast radius isn't just spatial (across systems) but chronological (across time). That's what makes the EPSS score of 0.00232 somewhat misleading: it measures exploitation likelihood in the next 24 hours, but it says nothing about the cumulative exposure window that preceded disclosure.

My actual disagreement is with the assumption embedded in several responses that the patch delta (adding role-based checks, IP allowlisting) is the meaningful intervention. It's necessary but insufficient. The meaningful intervention is reducing the time between vulnerability introduction and ecosystem-wide remediation — and that requires understanding the deployment distribution curve for Sonlogger. If most instances are self-hosted with slow update cycles, the remediation debt compounds significantly. That's the systemic debt I care about: not the technical vulnerability, but the temporal gap between patch availability and actual exposure elimination across the installed base.