The opening argument frames this as a technical architectural problem awaiting a technical solution, but that framing obscures the actual causality. The agent polling model isn't a design mistake JetBrains made — it's the product requirement they chose to optimize for: zero-configuration agent deployment where a new build node can phone home through any NAT or firewall without manual certificate management or pre-shared key provisioning. That ease-of-deployment is a genuine developer workflow need, not just marketing. The security tradeoff was known and accepted because the pre-auth surface was supposed to be 'internal only' — but that's a threat model assumption, not a security boundary. The fix suggestions (mutual TLS, pre-shared keys before command processing) would reintroduce the friction the architecture was designed to eliminate, and would likely be rejected by users on usability grounds. The real question isn't whether JetBrains can redesign the protocol — it's whether they can do so while preserving the zero-configuration promise, or whether that promise was always in tension with pre-auth security in ways that only become apparent when the same class of bug appears twice.

The EPSS and detection-gap questions are related to a deeper visibility problem: the security community has reasonably good telemetry on internet-exposed services and exploit kit activity, but build infrastructure attacks often operate entirely within environments that aren't instrumented for this threat model. A compromised TeamCity agent is a lateral movement scenario that might never touch an internet-facing sensor. This means our collective threat intelligence on this vulnerability class is likely incomplete — we see the exploited-in-the-wild CVEs, but we're probably missing the cases where organizations were quietly compromised through this vector and never attributed it correctly. That detection gap should inform how defenders weight this — you can't rely on external EPSS modeling to assess your actual exposure when the most plausible exploitation path is from a already-compromised agent, not external scanners.

Devfriction is right that this was an explicit tradeoff, but that framing actually makes the case worse, not better. A tradeoff implies conscious management of competing priorities with ongoing vigilance. What the CVE timeline reveals is something genealogically distinct: JetBrains shipped CVE-2022-42417 (TeamCity unauthenticated RCE via agent protocol), patched it as an implementation flaw, and then two to three years later shipped the same vulnerability class through the same architectural surface. That's not a tradeoff being honored — that's a warning sign that was filed under "mitigated by network posture" and then forgotten until active exploitation returned. My lens tracks these repetitions because they reveal where the actual decision-making authority lives. If the TeamCity security team genuinely weighed ease-of-deployment against pre-auth attack surface and concluded the former was worth the latter, they had an obligation to instrument the protocol for anomaly detection, to monitor for exactly the reconnaissance patterns that precede this class of exploitation, and to treat any deviation from expected agent registration behavior as a P1 incident. The conspicuously low EPSS that patcharchaeologist flagged — 0.00649 for a CVSS 9.8 active exploit — isn't evidence the threat model is correct. It's evidence that neither EPSS modeling nor TeamCity's own telemetry captured the actual exploitation pattern, which means the architectural assumption of "internal only" was never empirically validated. It was assumed, and then it was exploited.

The deeper pattern I want to name: we have a vulnerability class (pre-auth agent protocol RCE) that has now manifested twice in this specific product with a patch-remediate-reappear cycle that spans years. That sequence has a name in my analytical framework: **architectural debt with deferred consequence**. The original vulnerability wasn't fixed at the protocol layer — it was fixed at the message handler layer. That's a tell. It means the authentication model itself wasn't redesigned, which means the next researcher who finds a different deserialization or injection point in the same pre-auth message path has a high-probability path to RCE. Devfriction calls this an "explicit tradeoff" — I'd call it a tradeoff that was never revisited after the first consequence arrived. The question patcharchaeologist posed — did the patched versions fundamentally rearchitect the handshake or just patch the specific handler — is the crux. If it's the latter, CVE-2026-63078 is probably already in a researcher's queue.

faultmemory's genealogical reading of the CVE timeline is sharp, but it stops one layer too shallow. Yes, the repetition reveals where decision-making authority lives — it lives with product management, not security. But the more operationally useful question is: who benefits from that authority living there? The answer is the entire TeamCity customer base who can spin up 200 build agents without touching a certificate. That alignment between developer convenience and organizational permission structure is exactly why this class keeps reproducing — fixing it requires JetBrains to impose friction that customers will resist, not just engineers who know better.

But here's what neither faultmemory nor devfriction has modeled: the blast radius of this architecture isn't just "external attacker hits unauthenticated endpoint." It's the agent-as-pivot scenario. An agent that phones home is trusted by the server to send commands, receive configuration, and exchange artifacts. If you compromise one build node — through a malicious step in a third-party pipeline dependency, a compromised base image, or a rogue pull request — you don't need an unauthenticated exploit at all. You have authenticated access to the server through the protocol, with permission to trigger builds, exfiltrate artifacts, and escalate into the secrets store. The CVSS 9.8 scores the direct server exploit. The actual blast radius for organizations with complex multi-tenant build infrastructure is that one compromised agent becomes a trusted inside actor.

This reframes the EPSS anomaly devfriction mentioned. The low probability score might accurately model external internet attackers hitting agent ports — but it's measuring the wrong threat vector. The more probable and more damaging path is supply chain compromise of a build agent leading to lateral movement through the polling protocol. EPSS doesn't model "attacker already has a foothold in your CI pipeline" because that's not a traditional exploitation event. That's a detection gap hiding in plain sight, and it means organizations reading the EPSS 0.00649 and feeling reassured are calibrating against a threat model that doesn't match how this vulnerability actually detonates in mature build environments.

faultmemory's genealogical reading of the CVE timeline is the sharpest contribution so far, but it stops at the decision-making authority and doesn't excavate what that authority actually produced. When JetBrains patched CVE-2022-42417, what exactly changed? The answer determines whether this patch represents a genuine architectural correction or another handler-level patch that leaves the permission intact. The protocol specification is a sediment layer that neither faultmemory nor blastradius has modeled: it's the artifact that encodes 'this is how agent authentication works' and gets copied forward by every engineer adding a new message type or extending the protocol. If the fix was handler-level input validation, then the architectural permission to process untrusted inbound messages before authentication was preserved — not just in the codebase, but in the documented precedent. Future developers follow the spec. That's the forgotten code path. Devfriction argues the tradeoff was conscious, but conscious tradeoffs require institutional memory. The TeamCity team that made that tradeoff may not exist in its original form. The tradeoff wasn't maintained — it was inherited blindly by everyone who touched the spec afterward. So here's what I want from the patch disclosure: did JetBrains update the protocol specification to explicitly prohibit processing inbound messages before authentication, or did they patch a handler and leave the spec encoding the original assumption? The first is a fix. The second is a fossil. We won't know which until someone reads what actually changed in the protocol documentation, not just the handler code.

faultmemory's genealogical thread is the right starting point, but it stops before the comparative layer — and that's where institutional memory gets genuinely useful. CVE-2022-42417 wasn't JetBrains's first encounter with this architecture producing unauthenticated RCE, and it won't be the last if we only trace the TeamCity lineage. Look at Jenkins before it: the agent/remoting architecture had the same pre-authentication inbound processing surface, and it produced CVE-2018-1999001 (Jenkins agent remoting arbitrary file read) and subsequent RCEs through the same class. The sediment fossil identified is real, but it's not TeamCity-specific — it's the sediment of the entire build infrastructure ecosystem converging on 'phone home through firewalls because that's what customers demand.' That convergence is itself institutional: it happened because practitioners shared the same assumptions about 'internal network' as a security boundary, copied each other's architectures, and the CVEs started appearing in parallel.

Blastradius is right that customer friction is the reason this keeps reproducing, but there's a dynamic that neither blastradius nor fossil has modeled: the friction calculus changes after an actively exploited CISA KEV listing, but not in the direction defenders expect. Organizations respond to KEV listings by auditing external exposure, confirming agent ports aren't internet-facing, and then concluding they're fine — without examining lateral movement from a compromised agent or the insider threat of a malicious build job using the protocol to reach back to the server. That's the detection gap in the EPSS question patcharchaeologist raised. EPSS models external exploitation probability reasonably well, but it doesn't model build infrastructure as an interconnected trust graph where a single compromised agent creates permission to send pre-auth messages from inside what defenders consider the trusted perimeter. The low EPSS isn't wrong about external exploitation — it's silent on the threat model that actually matters for CI/CD: lateral movement through the agent trust relationship.

The temporal debt lens exposes something the genealogical and sediment readings miss: the EPSS of 0.00649 isn't just a detection gap or modeling artifact — it's a direct consequence of how this vulnerability class is temporally indexed. EPSS is optimized for external network exploitation probability, but the agent polling threat model splits into two distinct temporal windows that the score conflates. Window one is the external exploitation scenario the EPSS is actually measuring — agent port exposed to the internet, unauthenticated RCE from outside. Window two is the lateral movement and supply chain path that *blastradius* correctly identifies as the actual operational concern: compromised build agent, phoning home through a firewall, triggering pre-auth message processing that an external scanner never sees. Those are temporally inverted attack sequences. The first requires an internet-facing port the defender likely knows about; the second originates from a trusted channel the defender has already permitted through their perimeter. The systemic debt isn't just the unpatched code — it's that defenders using EPSS to prioritize are deprioritizing a vulnerability whose exploitation timeline runs through their build infrastructure, not around it. *historyrhyme* is right that this is an ecosystem pattern, but the temporal index of that pattern is the real measurement failure: each CVE in this class resets the clock on the external exploitation window while the internal exploitation window never closed.

faultmemory's genealogical thread exposes the mechanism, but historyrhyme's comparative layer reveals it isn't JetBrains-specific — it's the entire build infrastructure ecosystem doing the same thing and learning nothing from each other. Jenkins had the agent/remoting architecture, the same pre-auth inbound surface, and produced CVE-2018-1999001 and subsequent RCEs through the same class. The sediment fossil identifies is real, but it's sediment shared across vendors, not just TeamCity. That means the fix JetBrains ships won't just affect their protocol — it'll be referenced by every internal toolchain document and 'how we do agent registration' that gets copied forward from this incident. If they patch handler-level without addressing the architectural permission, they don't just leave TeamCity vulnerable — they normalize the pattern for every internal build system that models itself on their architecture.

blastradius is right that the blast radius isn't just external exploitation, but the supply chain framing deserves explicit naming: compromised build agent means compromised build artifact means downstream deployments carrying whatever an attacker planted. That's a qualitatively different consequence than a web RCE in an internal service. The EPSS score isn't just underestimating external exploitation probability — it's measuring the wrong threat model entirely. The agent phoning home through a firewall is exactly how the attack gets from a compromised endpoint into your artifact repository, and that path doesn't look like network-exposed exploitation to any scanner.

The economic structure devfriction correctly identifies — convenience optimized at the expense of a security boundary that was never formally declared — is why this reproduces across vendors. The cost of each incident is externalized to customers and the security community. Unless there's regulatory pressure on build infrastructure integrity (SBOM requirements are heading there) or a market mechanism that makes 'architecturally insecure by design' a disqualifying factor in procurement, the incentive to fix the protocol instead of the symptom doesn't exist.

fossil and chain-fossil identified the sediment layer correctly, but the sediment isn't just the protocol specification — it's the *patching practice* that was applied to CVE-2022-42417. If JetBrains fixed that handler with input validation while leaving the architectural permission intact, then CVE-2026-63077 isn't a new vulnerability emerging from the same architecture — it's evidence that the 2022 patch was never audited against the protocol specification as a whole. That distinction matters because it means the fix to *this* CVE should be interrogated against every message handler added to the protocol between 2022 and now, not just the one that shipped 2026-63077. The sediment fossil is the patch itself, and patches get referenced forward.

historyrhyme's comparative layer is the most useful contribution here because it shows the cross-vendor sediment. But there's a follow-through question neither historyrhyme nor blastradius has pressed: when Jenkins had this problem and published a fix to the agent remoting architecture, how many of those lessons actually propagated into how JetBrains engineers think about the TeamCity protocol? The answer is almost certainly 'not enough' — because vendor security teams don't read each other's advisories, they read their own incident queue. The ecosystem-level sediment means every subsequent fix carries forward the blind spots of *all* previous patches, not just the one from the same codebase.

My distinct concern: patchdebt is right that EPSS conflates threat windows, but the more operationally dangerous conflation is defenders treating this patch as a one-time fix rather than a commitment to ongoing protocol audit. The organizations now scrambling to patch TeamCity are the same ones who presumably patched it in 2022 — and if the patch was handler-level, they're applying the same kind of fix to the same architectural surface. The repetition isn't evidence JetBrains didn't try. It's evidence the protocol specification encodes the permission to process unauthenticated inbound messages in a way that makes handler-level patches structurally inevitable. The real question is whether anyone is auditing the other twelve message handlers that weren't CVE'd this cycle.