Random Chaos

Your AI security tool blocks nothing

Mon, 25 May 2026 00:00:00 GMT

1. Opening Claim

The AI cybersecurity market is selling outcomes it cannot prove. Vendors are pricing tools as if detection is a solved problem. It is not. The control surface has not changed. The marketing has.

I run red team operations against environments protected by these tools. The gap between what is advertised and what blocks an operator on a Tuesday morning is wide. AI labels on a SIEM do not change the identity boundary. They do not change execution context. They do not change trust relationships between systems. They change the dashboard.

Most of what is being sold as AI-powered defence is statistical anomaly detection wrapped in new vocabulary. Some of it works. Most of it adds alerts. Almost none of it removes attacker capability. That is the position. The rest of this is the breakdown.

2. The Original Assumption

The assumption behind the current wave is that machine learning models can identify malicious behaviour faster and more accurately than rule-based detection, and that the gain compounds as data volume grows. The pitch positions AI as a multiplier on existing security operations. Same analysts. More coverage. Fewer misses. That is the contract being sold.

That assumption depends on three conditions. The model has access to telemetry that captures the actual attack path. The training data reflects current attacker behaviour. The output is actionable inside the response window. If any one of these conditions is missing, the system produces volume, not defence. None of the three are automatic. Each is an engineering problem that the vendor does not own.

The market behaved as if all three were given. Procurement cycles compressed. Tools were deployed across identity, endpoint, network, and cloud layers in parallel, often without a defined detection contract. The shared assumption was that the model would close the gap regardless of how it was wired in. That is a procurement posture, not a security posture. It is not supported by control engineering and it is not supported by red team outcomes.

3. What Changed

Attackers adopted the same toolset. Generative models lowered the cost of phishing content, payload variation, and reconnaissance at scale. Credential stuffing campaigns now produce per-target context. Voice cloning is operationally available. The defender does not get the AI advantage alone. The attacker gets it cheaper, because the attacker does not have a compliance team, a procurement cycle, or a change window.

The detection surface also moved. Identity-based attacks (token theft, OAuth consent abuse, session hijack, federated trust abuse) do not look like malware. They look like a valid user doing valid things from a valid endpoint. A model trained on behavioural baselines cannot reliably separate a compromised session from a legitimate one without explicit signals at the identity boundary. Many environments do not emit those signals. That is a logging architecture problem. A model cannot solve it.

What changed is the cost structure on both sides and the location of the failure. In most enterprise compromises I have observed, the failure is not at the perimeter and not at the endpoint. It is at identity, federation, and third-party trust. AI tooling marketed for endpoint and network detection does not address that surface. Buying more of it does not move the boundary. The exact dwell time, scope, and persistence of attacker activity inside these environments is not confirmed in any standardised industry dataset I would cite as fact. What is confirmed is the location of the gap, and the gap is not where the spend is going.

4. Mechanism of Failure or Drift

The mechanism is substitution. A model label is placed on top of an existing detection pipeline and the pipeline is treated as upgraded. The underlying telemetry, the integration points, the response workflow, the analyst capacity. None of these change. The control surface is identical to what existed before procurement. What changed is the confidence the buyer has in it. Confidence is not a control.

When the model produces an alert the team cannot triage inside the response window, the alert is noise. When the model produces a verdict the team cannot act on without manual investigation, the model has not reduced workload. It has redistributed it. In several engagements I have run, average alert dwell in the analyst queue exceeds the time required for an operator to complete privilege escalation and stage exfiltration. That measurement is not confirmed as a uniform industry metric. It is consistent in the environments I have tested. The detection exists. The response does not.

Model drift is the second failure mode. A behavioural baseline trained on a six-month window does not reflect the environment after a cloud migration, a workforce change, or an identity provider swap. The model continues to issue verdicts. The verdicts no longer map to current conditions. Unless the vendor and the customer have a defined retraining contract and a feedback loop, the model degrades. Silent degradation of a control is worse than no control. The buyer is still operating on the assumption that the control is enforced. The attacker is operating on the assumption that it is not. Only one of those assumptions is being tested in production.

5. Expansion into Parallel Pattern

The pattern is older than AI. The same substitution mechanism appeared with SIEM deployments in the previous decade. A platform was purchased, log sources were connected, dashboards were built, and the security posture was reported as improved. The detection content was not written. The response workflow was not defined. The alerts that fired were not triaged. The platform was present. The control was not. AI security tooling is being deployed on the same procurement reflex, against the same gap, using the same logic.

The mechanism is the introduction of a labelled artifact where a defined control is required. A control is a stated decision about what behaviour is permitted, what is blocked, who is notified, and who is accountable when it fails. A model verdict is none of these by default. It becomes a control only when it is wired into an enforcement point with a defined owner and a defined action. Most current deployments stop at the verdict. The enforcement point is left as an exercise for the customer. The accountability is left undefined. The verdict is treated as if it carries authority. It does not. It carries an opinion.

This pattern produces a specific failure shape. The audit trail shows extensive detection coverage. The incident timeline shows the activity was visible. The response gap remains because nothing in the chain forces action on the verdict. The post-incident review identifies the detection as having worked. The compromise still occurred. The buyer concludes the tool needs tuning. The actual issue is that detection was never connected to a decision boundary. More tuning does not fix the absence of a decision boundary. More models do not either. The pattern is structural, not technical.

6. Hard Closing Truth

AI does not change the security contract. Identity is still the boundary. Execution context still determines blast radius. Trust relationships still define lateral path. A model that does not change one of these is not a security control. It is telemetry with a verdict attached. Telemetry with a verdict attached has a place in a security program. That place is upstream of a decision, not in place of one.

What must now be true. Every AI detection capability in the environment is mapped to a specific enforcement point, a specific owner, and a specific response action with a defined time window. If the verdict does not trigger an enforced outcome inside that window, the capability is logging, not defence. It can stay in the stack. It cannot be counted as a control. The distinction must be reflected in the risk register, in the control matrix, and in the way the program is reported to leadership. Calling logging a control is the mechanism that produced the original gap. Repeating it under a new label produces the same outcome at higher cost.

The operator position is direct. Stop buying verdicts. Buy enforcement. Where enforcement is not available, buy visibility that a defined human or automated process will act on inside a stated window, with named accountability when the window is missed. Anything else is shelfware with a model attached. The attackers using the same tooling are not subject to procurement cycles, change windows, or compliance reviews. The defenders are. That asymmetry is the operating condition. It is not solved by purchasing more of what produced it. It is solved by treating identity, execution context, and trust as the only surfaces that matter, and refusing to count anything that does not move them.

See also: NordVPN for tunneled traffic when operating outside controlled networks.

#ad Contains an affiliate link.

Dutch police seized the provider

Sun, 24 May 2026 00:00:00 GMT

1. Opening Claim

Dutch authorities seized 800 servers from a hosting firm identified as enabling cyberattacks. The action targets the infrastructure layer directly, not the tenants operating on it. The stated condition is enablement. That word matters. It places the provider inside the attack chain, not adjacent to it.

This is not a tenant-level takedown processed through abuse channels. It is a removal of the provider’s operational capacity at scale. Eight hundred servers is the stated count. The specific identity of the firm, the customers hosted on those servers, the categories of cyberattack involved, and the duration of the activity are not confirmed in the facts provided.

What is confirmed is the shape of the action. A state authority judged the hosting environment itself to be the locus of harm and acted against the operator. The standard model where hosting is treated as neutral transport does not apply to this case. The provider was treated as a party to the activity, and the response matched that classification.

2. The Original Assumption

The default operating assumption across most enterprise threat models treats hosting providers as neutral intermediaries. They route traffic, lease compute, respond to abuse reports, and sit outside the attack lifecycle for modeling purposes. Detection logic focuses on tenant behavior. Attribution stops at the IP or ASN. Takedown requests follow abuse contact procedures. The provider is treated as a channel, not a participant.

This assumption is a simplification. It exists because the alternative, modeling every transit and compute provider as a potential adversary, is operationally unworkable for most defenders. So the threat model draws the boundary at the tenant and trusts the provider tier to remain out of scope. Identity boundaries are defined per workload. Trust is extended to the underlying infrastructure by default.

The assumption has known failure modes. Hosting environments that ignore abuse complaints, registrars that protect malicious tenants, and infrastructure operators who price their service against the level of operator scrutiny they will accept have existed alongside legitimate providers for a long time. The assumption did not deny this. It deferred it. The provider tier was treated as someone else’s enforcement problem, typically law enforcement or upstream peers. Defenders worked around the gap rather than closing it.

3. What Changed

The seizure moves the unit of enforcement from the tenant to the provider. 800 servers were taken. The action was directed at the hosting firm, not at specific customers identified on those servers. The boundary that historically separated the operator from the activity on its platform was not honored in this case.

For the provider tier, this redefines the operating boundary. If the firm itself is judged to be enabling attacks, the entire footprint becomes available for state action. Customer separation, contractual neutrality language, and tenant isolation do not insulate the provider from consequences tied to the aggregate behavior on its platform. The enablement determination collapses the distinction between operator and operation.

For any workload that was running on those servers, the outcome is direct. The compute is gone. Continuity, recovery paths, and data access for tenants operating on that infrastructure are not addressed in the facts provided and are not confirmed. What is confirmed is that the provider’s enablement was the trigger, and the tenants inherited the result. The action did not negotiate with the tenant layer. It removed the layer beneath it.

4. Mechanism of Failure or Drift

The drift was structural. Defenders modeled the tenant. Law enforcement modeled the provider. Neither party owned the space between them. The hosting tier sat in a jurisdictional and operational gap where aggregate harm could accumulate without any single defender being responsible for measuring it. The tenant-level threat model had no field for provider posture. The law enforcement process had no continuous telemetry from the defender side. Each party operated on its own surface and trusted the other to handle the rest.

Inside that gap, the enablement condition formed. A provider that does not enforce abuse, does not verify identity at signup, does not respond to takedowns, and does not separate workloads creates an environment where attacker workloads behave the same as legitimate workloads from the platform’s point of view. Enforcement that depends on the operator’s cooperation does not function when the operator’s commercial model is shaped around the absence of that cooperation. The control was named. The control was not enforced. Under the operating philosophy that controls which are not enforced are not controls, the abuse process at this provider was not a control. It was a label.

The Dutch action did not introduce a new mechanism. It applied an existing one, criminal seizure, to a layer that had been treated as out of reach. The drift was the assumption that this layer would remain out of reach. Eight hundred servers is the stated count of the correction. The number describes the scale of what had accumulated under the prior assumption. It does not describe attacker behavior, dwell time, or victim count, none of which are confirmed. It describes the size of the gap that defenders and operators had collectively agreed not to close.

5. Expansion into Parallel Pattern

The same mechanism applies to any tier where enforcement is named but not executed and where the operator’s commercial incentives are not aligned with the control. Domain registrars that accept anonymous registration at volume, payment processors that do not validate merchant identity, and bulletproof email relays operate on the identical pattern. The control surface exists in policy. The enforcement surface does not exist in practice. Attacker workloads use the tier the same way legitimate workloads do, because the tier does not differentiate. Aggregate harm accumulates at the operator. The operator is treated as neutral until a state authority decides it is not.

The condition that converts a tier from neutral to in-scope is the enablement determination. In the seized hosting case, the determination was made externally by Dutch authorities based on facts not provided. The mechanism of the determination is what defenders should extract. Once an infrastructure operator is judged to be a party to the activity it hosts, tenant separation does not function as a shield, contractual neutrality does not function as a shield, and the entire footprint becomes available for action. This is true at every tier that depends on the operator-as-neutral framing to keep itself out of scope. The framing is conditional, not permanent.

For defenders operating workloads on third-party infrastructure, the parallel is direct. The provider tier carries a risk that is not addressed by tenant-side controls. If the provider is determined to be enabling, the tenant inherits the seizure regardless of its own posture. This is not a hypothesis about attacker behavior. It is an observation about how enforcement now reaches across the tenant boundary when the operator is judged to be inside the chain. Workload placement is a control decision. The posture of the underlying provider is part of the workload’s exposure surface. It is not external to it.

6. Hard Closing Truth

Hosting is not neutral. The neutrality framing was a working assumption maintained by defenders, regulators, and operators in parallel. It is no longer reliable. When a state authority can act against the provider tier at the scale of 800 servers based on a determination of enablement, the provider tier is in scope. It is in scope for the operator, who can lose the platform. It is in scope for the tenant, who can lose the workload. It is in scope for the defender, who can lose visibility and continuity in a single action that did not originate from the tenant’s own behavior.

The operator position is the following. Provider posture is now a control input. Workload placement decisions must include the enforcement behavior of the provider, not only its technical capability and price. A provider that does not enforce abuse, does not verify identity, and does not separate workloads is a provider that has accepted the conditions under which a state authority may decide to act against it. Workloads placed on that provider carry the same exposure. The control failure does not have to be the tenant’s to produce a tenant outcome.

For providers, the position is simpler. Enablement is now an externally assessable condition with a defined consequence. A control that exists only in policy is not a defense against that assessment. The 800 servers are the demonstration. The firm operated the infrastructure. The firm was judged to be inside the chain. The firm lost the infrastructure. Any provider whose enforcement surface does not match its policy surface is operating under the same conditions and should plan accordingly. Identity is the boundary. Trust must be continuously validated. If a system allows it, it will happen, and the operator will be held responsible for having allowed it.

Microsoft is sending the spam itself

Sun, 24 May 2026 00:00:00 GMT

Opening position

Spam links are being delivered from inside a Microsoft-controlled identity boundary. The sending identity is described as an internal Microsoft account. The specific account, tenant, or service is not confirmed. The volume, duration, and number of recipients are not confirmed.

The operational fact is simple. Messages reaching end users carry a sender identity that resolves to Microsoft infrastructure. That identity is the boundary. When the boundary itself is the source, every downstream control built on sender reputation, domain authentication, and trusted-vendor allowlisting is operating on a premise that no longer holds.

This is not a phishing case where an attacker imitates a brand from an external domain. The sending surface is internal to the provider whose name the recipient already trusts. Treat that distinction as the central condition of this event. Everything that follows is shaped by it.

What actually failed

Observable behaviour: outbound messages containing spam links are being sent from an account described as internal to Microsoft. Recipients receive content that originates from, or appears to originate from, infrastructure under Microsoft’s control. Whether the account is a compromised tenant, a service identity, a provisioning artefact, or a legitimate account being abused by its assigned user is not confirmed.

What this means at the delivery layer is direct. SPF, DKIM, and DMARC checks tied to Microsoft-controlled sending infrastructure are not the failure surface here. Those mechanisms validate that mail originated from where it claims to originate. In this case, the claim is accurate. The mail did come from where it says it came from. Authentication passing is not a control failure. It is the system behaving as designed against an identity that should not have been permitted to send this content.

The failure visible from outside the provider is at the abuse-prevention layer for outbound sending from internal accounts. Content was generated, queued, and delivered. Recipient-side filtering did not interdict it at a rate sufficient to prevent the campaign from being noticed. Whether internal Microsoft controls detected and acted on the activity, and on what timeline, is not confirmed. The only confirmed signal is that messages reached recipients in a volume large enough to surface as a reported pattern.

Why it failed

The mechanism that enabled the outbound activity is not confirmed. What is logically necessary from the stated facts is this: an account inside Microsoft’s identity perimeter was in a state where it could send messages containing spam links to external recipients, and the controls governing that account either permitted the activity or did not stop it before delivery. One of those two conditions holds. Both are control failures of the same class.

Identity is the boundary. When the sending identity sits inside the provider, the controls that matter are the ones the provider applies to its own accounts: provisioning hygiene, authentication strength on the account, behavioural detection on outbound sending patterns, rate and content controls on messages leaving the platform, and revocation speed once abuse is identified. Which of these were present, which were enforced, and which were bypassed is not confirmed. The absence of effective enforcement is the only condition the observed behaviour supports.

A control that does not stop the behaviour it exists to stop is not a control. If outbound abuse detection on internal accounts was in place and the messages still went out at scale, the detection is ineffective in its current configuration. If the account type involved is one that is not subject to the same outbound controls as standard tenants, that scoping decision is the failure. If the account was legitimately provisioned and later misused without re-validation of intent, the trust model is the failure. The specific path is not confirmed. The category is.

Mechanism of failure

The mechanism, reduced to its operative parts, is this: an identity inside the provider’s perimeter held the capability to emit outbound messages containing spam links, and the enforcement surface between that capability and external recipients did not interrupt the activity before delivery. The specific account class, the specific sending path, and the specific control that was absent or bypassed are not confirmed. What is logically necessary is that capability existed, enforcement did not, and delivery occurred.

Three control surfaces are implicated by the observed behaviour. The first is the account state itself, meaning whatever conditions had to be true for that identity to be in good standing as a sender at the moment the messages were emitted. The second is the outbound content and behavioural inspection applied to messages originating from internal identities, meaning whatever the provider runs against its own sending surface before mail leaves the platform. The third is the revocation and rate-limiting response once the pattern became observable externally. Which of these was the primary failure point is not confirmed. The condition that one or more failed is supported by the fact that messages reached recipients in volume sufficient to be reported.

The distinction that matters operationally is between controls that were absent by design and controls that were present but ineffective. An account class exempt from outbound abuse controls is a scoping failure in the trust model. An account class subject to controls that did not detect this content is a detection failure in the enforcement layer. An account where detection fired but revocation lagged is a response failure. These are three different problems. Treating them as interchangeable produces remediation that addresses none of them. The provider’s internal telemetry would distinguish them. External observers cannot. For anyone receiving this mail, the operational posture is identical regardless of which one is true: the sender label cannot be used as a trust signal for this class of message.

Expansion into parallel pattern

The pattern is the use of a trusted sending surface to deliver content that would be filtered or refused if it originated elsewhere. The trust attaches to the surface, not to the content. Once an identity inside a high-reputation perimeter is in a state where it can emit, the downstream filtering that recipients and their providers apply is operating against a sender that authentication, reputation, and allowlists are designed to admit. The content rides the identity. The identity is the access path.

This pattern repeats wherever a provider operates both an identity boundary and a delivery surface, and where the provider’s name is itself a trust signal to recipients. The same mechanism applies when calendar invitations, file-share notifications, collaboration mentions, or transactional alerts are emitted from a provider-controlled identity carrying attacker-supplied content. In each case, the sender field, the domain, and the authentication chain are accurate. The control that would have to fire is one that inspects the content and behaviour of the internal identity itself, not one that validates where the mail came from. Where that inspection is absent, weak, or scoped to exclude certain account classes, the pattern is reproducible.

The operational consequence is that recipient-side controls built on sender reputation cannot interdict this class of abuse without producing collateral blocking of legitimate provider traffic. Recipients face a binary choice: trust the surface uniformly, or distrust it uniformly. Neither is a control. The control has to live with the provider, applied to the provider’s own identities, enforced on the outbound path before mail leaves the platform. When that enforcement is incomplete, the cost is externalised to every recipient organisation and every end user who has been trained to treat the provider’s name as a reason to engage with the message.

Hard closing truth

The sender field is not a control. The domain is not a control. Authentication passing is not a control. These are facts about where a message originated. They are not statements about whether the message should have been sent. When the originating identity sits inside a trusted provider’s perimeter, the only control that matters is the one the provider applies to its own accounts before the mail leaves the platform. If that control is absent or ineffective, every recipient is exposed and no recipient-side configuration closes the gap.

Identity is the boundary. Trust attached to an identity must be continuously validated against the behaviour of that identity, not assigned once at provisioning and carried forward indefinitely. An account that begins legitimate and later emits abuse is the same account from the perspective of authentication and reputation. It is a different account from the perspective of what it is doing. Systems that do not measure the second cannot defend against the first becoming the second. The observed behaviour is consistent with a trust model that did not re-evaluate in time.

What must now be true is straightforward to state and the provider’s responsibility to enforce. Outbound content and behavioural controls apply uniformly to every internal identity class capable of sending external mail, with no scoping exemptions that create silent emission paths. Detection on outbound abuse from internal identities operates at a latency short enough that revocation precedes delivery at scale, not after. The sender label stops being treated, internally or externally, as a sufficient condition for trust. Until those conditions hold, the boundary is permeable in the direction that matters most, and the recipients carry the exposure that the controls did not.

See also: NordVPN for tunneled traffic when operating outside controlled networks.

#ad Contains an affiliate link.

Ten thousand bugs from one vendor's machine

Sun, 24 May 2026 00:00:00 GMT

1. Opening Claim

Anthropic has stated that Mythos has found more than 10,000 vulnerabilities. That number is the operational fact. Everything else around it is vendor framing, third-party interpretation, or inference. Treat it accordingly.

The statement is a claim about output volume. It is not a claim about severity distribution, exploit viability, disclosure status, or downstream remediation. The class of vulnerability is not confirmed. The targets are not confirmed. The validation pipeline behind each finding is not confirmed. Uniqueness, deduplication, and false positive rate are not confirmed. For an operator reviewing this, the only load-bearing element is the order of magnitude.

That order of magnitude is the part that matters. A single vendor-controlled system producing five-digit volumes of vulnerability findings changes the cost curve of discovery. If the claim holds at face value, automated discovery at this scale is now a position a model vendor can occupy. The asymmetry between attacker discovery capability and defender remediation capability moves. It moves in one direction. It does not move back when the announcement cycle ends.

2. The Original Assumption

Most security programs are built on the assumption that vulnerability discovery is the constrained resource. Internal AppSec teams cannot reach full coverage of their own estate. External coverage is bought through bug bounty programs, scheduled penetration tests, static and dynamic analysis tooling, and academic disclosure. Each of these channels is bounded by skilled human labour and the time those humans can spend on a given target.

Patch pipelines, vulnerability management tooling, ticket SLAs, and risk acceptance workflows are all sized to that inflow rate. A critical SLA of seven days, a high SLA of thirty, a medium SLA of ninety: these numbers are not engineering constants. They are accommodations of a finding rate that human-led and tool-assisted research has historically been able to sustain. Risk registers carry open issues for full quarters because the inflow matches the outflow within tolerance. The program looks like it is functioning.

The assumption underneath that picture is that discovery and remediation operate at comparable rates over time. If that assumption holds, the backlog is stable. If discovery is decoupled from remediation and runs at a multiple of it, the backlog grows without bound. The risk register stops being a register and becomes a record of exposure. Every control built on top of the original assumption, including SLA-based escalation, severity-weighted triage, and acceptance workflows, is sized for a world that may no longer be the world the organisation operates in.

3. What Changed

The stated fact is that Mythos has produced more than 10,000 vulnerability findings, per Anthropic. The composition of that 10,000 is not confirmed. Whether the findings are unique, whether they were validated against false positives, whether they map to live production systems or to source code artefacts in isolation, whether they cluster in a small number of codebases or are distributed across many, is not confirmed in the public claim. Disclosure status of individual findings is not confirmed. Patch status is not confirmed.

What the claim does establish, if taken at face value, is that an automated system operated by a model vendor is producing vulnerability output at a volume that exceeds the annual output of any single human research team on public record. The defender position of “discovery is the bottleneck” cannot be assumed for any organisation that such a system is directed at. The direction of the system is the operative variable. Findings against a given codebase, a given dependency, a given piece of infrastructure, surface on the operator of the system’s timeline. Not on the owner’s timeline.

The remediation side of the equation has not changed. Patch cycles, change approval windows, dependency upgrade discipline, regression test capacity, and deployment cadence operate at the same rate they operated at before this announcement. No part of the defender’s pipeline has been accelerated by the existence of Mythos. The component that shifted is the upstream rate of confirmed-or-claimed vulnerability identification. The gap between identification and remediation widened. That gap is the operating window for anyone with access to findings before the owner does. Whether that population is restricted to the vendor, to its customers, to disclosure partners, or to a broader set, is not confirmed.

4. Mechanism of Failure or Drift

The failure is not located in any single control. It sits in the sizing assumption underneath the entire vulnerability management stack. Every SLA, every triage queue, every risk acceptance form is calibrated to a rate of incoming findings that has historically been constrained by skilled human research. When the upstream rate of a process is bounded by a slow input and the downstream rate is bounded by a slow process, the system reaches a working equilibrium. Remove the upstream constraint without changing the downstream process and the equilibrium does not hold. The remediation pipeline does not absorb the new rate. It carries the difference as backlog.

The drift in this instance is structural, not gradual. A single vendor-operated system is the stated source of more than 10,000 findings. The system is operated on a timeline the vendor controls. The findings surface in an order, at a cadence, and through a disclosure path that the operator selects. The owner of the affected system does not control any of those variables. The control that fails here is the implicit assumption of shared timing between the party that finds the issue and the party that owns the issue. That assumption was load-bearing in coordinated disclosure norms and in the SLA windows that triage queues use to schedule work.

The position the owner is now in is downstream of an external clock they do not see. Whether the disclosure path is coordinated, restricted, paid, or open is not confirmed for any given finding. Whether the findings are validated against false positives before disclosure is not confirmed. Whether they cluster on a small set of high-value targets or distribute across many is not confirmed. What is confirmed is the order of magnitude of the output and the identity of the party producing it. Identity is the boundary. In this case the boundary sits with the operator of the system, not with the owner of the code. A control framework that assumes the opposite is not enforced. It is described.

5. Expansion into Parallel Pattern

The mechanism is upstream automation running against downstream human-paced process. The pattern shows up wherever one side of an adversarial or quasi-adversarial relationship is automated and the other is not. Credential stuffing is the cleanest example of the same mechanism. Lists of breached credentials are tested against authentication endpoints at machine rate. The defender response, which is password rotation, MFA enrolment, and anomaly review, runs at human rate. The equilibrium that held while guessing was manual collapsed once guessing was automated. The defender side did not get slower. The attacker side got faster, and the gap between the two is the operating window for account compromise.

Phishing infrastructure follows the same shape. Domain generation, certificate provisioning, and template rendering run at machine rate. Takedown, blocklist propagation, and end-user reporting run at human rate. The infrastructure operator selects the timing of the campaign. The defender reacts on a clock the operator controls. The asymmetry is not a function of skill or budget. It is a function of which side of the pipeline has been automated. Once one side is automated, the other side becomes the constraint, and the constraint is where exposure accumulates. The pattern is mechanical, not motivational. The side that runs at machine rate sets the tempo of the entire system.

The same shape applies to vulnerability discovery once the discovery side is automated at the volume Anthropic has claimed. Patch cycles, regression testing, dependency upgrades, and deployment windows operate at the rate they operated at prior to this announcement. The discovery side, if the claim is accurate, operates at a rate that exceeds any historical human-led program on public record. The constraint moves from discovery to remediation. Exposure accumulates in the gap. The party controlling the upstream clock controls the duration of that exposure for any given finding. Whether that control is exercised, by whom, and against which targets is not confirmed. The mechanism is confirmed by the structure of the claim itself.

6. Hard Closing Truth

The number is 10,000-plus, per Anthropic. The composition is not confirmed. The targets are not confirmed. The disclosure path is not confirmed. The severity distribution is not confirmed. None of that changes the operator position. The operator position is that any program sized to a human-paced discovery inflow is now sized for conditions that may not hold. Controls that depend on shared timing between researcher and owner depend on a relationship that one party can now operate without the other party having visibility into it.

SLA-based triage is not a control against this. It is a scheduling artefact. A 30-day high-severity SLA assumes that the rate of incoming highs is bounded by something other than the queue itself. If the bound moves, the SLA does not move with it. The queue grows. Bug bounty programs are not a control against this either. They are a discovery channel sized to human researchers. Internal static and dynamic analysis tooling is not a control against this. It is owner-controlled discovery, which is the side of the equation that has not changed. None of these mechanisms address the structural shift the claimed volume implies. They address the conditions that existed before it.

What must now be true is that owners cannot assume parity between their own discovery rate and the discovery rate of any external automated system directed at their estate. Identity of who holds findings first is the variable that determines exposure duration. Trust in shared disclosure timing must be continuously validated against the operating reality of who is producing findings, at what volume, on what clock. If a system permits automated discovery at five-digit volumes to run against an owner’s code without the owner’s visibility, the system permits it. Controls that depend on it not happening are not controls. They are assumptions. State them as such or replace them.

Contains a referral link.

The storefront went dark by sundown

Sun, 24 May 2026 00:00:00 GMT

1. Opening Position

A merchandise site linked to Kash Patel was taken offline following a reported compromise in which the site allegedly delivered malware to visitors. The site is dark. The delivery vector, the payload, the persistence mechanism, and the scope of affected visitors are not confirmed. What is confirmed is that a consumer-facing storefront, operating under the trust signal of a public figure’s name, served something it should not have served, and the operator’s response was to remove the surface entirely.

That response is the position to start from. Taking the site offline is containment. It is not remediation. It tells you the operator did not have a faster control to apply at the application layer, at the CDN layer, or at the content delivery boundary. The decision to pull the entire property indicates that selective takedown of the malicious component was either not possible or not trusted. That is a control posture statement on its own.

The broader signal is the one worth naming directly. A storefront tied to a recognisable identity is a high-trust delivery channel. Visitors do not inspect script tags. They do not validate certificate chains. They click because the name on the door is the name they expect. When that channel ships malicious code, the trust is the delivery mechanism. The brand is the payload carrier. Everything downstream of that point is consequence.

2. What Actually Failed

The externally observable failure is this: a site under the operator’s control returned content to visitors that is alleged to have been malicious. The site is now unreachable. Whether the malicious content was injected into the site’s own served HTML, loaded through a third-party script reference, or delivered via a compromised dependency in the storefront stack is not confirmed. The only externally observable behaviour is that visitors received something harmful and the operator removed the origin.

The second failure is containment scope. The operator did not isolate a component. The operator removed the property. That outcome tells you the boundary between trusted and untrusted content inside the application was not enforceable at a granularity smaller than the whole site. If the malicious code had been confined to a known module, a known script reference, or a known asset path, that element could have been pulled while the rest of the storefront continued to serve. It was not. The blast radius of the response equals the blast radius of the application.

The third failure is visitor-side. Anyone who loaded the site during the window in which malicious content was being served executed that content in their own browser. The duration of that window is not confirmed. The number of affected sessions is not confirmed. The payload behaviour, whether it targeted credentials, session tokens, payment input fields, or browser-level persistence, is not confirmed. What is confirmed is that the trust relationship between visitor and origin was the mechanism that allowed execution. The browser ran the code because the origin said to run it.

3. Why It Failed

Do not describe the failure as a hack in the abstract. Describe it as a control gap. A storefront serving unauthorised content to visitors means one of a small set of conditions was true at the moment of delivery: the origin was modified, the supply chain feeding the origin was modified, or the delivery path between origin and visitor was modified. Which of those conditions applied here is not confirmed. The structural point is that integrity of served content was not continuously validated against an authoritative baseline. If it had been, deviation would have triggered a response faster than the public discovery that forced the takedown.

The second condition is identity and access boundary discipline at the publishing layer. Merchandise sites are operated by small teams, frequently through third-party platforms, with administrative access distributed across operators, developers, marketing staff, and external vendors. Each of those identities is a path to the origin. Whether any of those identities was the entry point in this incident is not confirmed. The pattern is that the number of identities authorised to change served content is almost always larger than the number of identities subject to enforced controls on those changes. That gap is where unauthorised modification happens.

The third condition is third-party execution context. Modern storefronts load analytics, tag managers, payment widgets, chat tools, A/B testing scripts, and pixel trackers. Each of those is code executing in the origin’s trust context. The origin operator typically does not control the code those vendors ship. A compromise of any one of those vendors becomes a compromise of every site that loads them. Whether a third-party dependency was the vector here is not confirmed. The exposure exists by design in the architecture of consumer web storefronts, and removing the site does not remove that exposure. It only removes the surface on which it was visible.

4. Mechanism of Failure or Drift

The mechanism is integrity drift at the published surface. A storefront publishes a defined set of assets, scripts, markup, and references. That published set has an authoritative state at the moment of deployment. Drift occurs when the served content diverges from that authoritative state without an authorised change event. In this incident, the served content allegedly diverged. The drift was visible to visitors before it was visible to the operator. That ordering is the failure. Detection arrived through external impact, not internal signal.

Drift at the publishing layer happens through one of three paths. The origin filesystem or database is modified directly by an identity with write access. A referenced third-party asset is modified at its own origin and pulled into the page on next load. A platform-level component, such as a theme, plugin, or tag manager configuration, is modified through an interface that maps back to the same served output. Which of those paths applied here is not confirmed. The mechanism that makes all three possible is the same: served content is treated as authoritative because it is served, not because it is verified. The browser does not ask whether the script it just received matches a known-good hash. It executes what arrived.

The drift is sustained by the absence of a continuous integrity check between the authoritative deployment state and the live served state. Subresource integrity attributes on script and link tags would constrain third-party drift at the browser level. Content Security Policy with strict source allow-lists would constrain injection of unauthorised script origins. File integrity monitoring at the origin would surface direct modification. Whether any of those controls were present here is not confirmed. The observable outcome is that drift reached visitors and ran in their browsers before any control interrupted it. A control that does not interrupt is not a control. It is documentation.

5. Expansion into Parallel Pattern

The pattern is not specific to merchandise sites and not specific to public figures. Any consumer-facing web property that loads third-party code, accepts administrative changes from multiple identities, and serves content under a recognised brand name operates with the same exposure profile. The Magecart class of incidents over the last several years established the shape. Attackers do not need to breach the brand to weaponise the brand. They breach a script the brand loads. The script executes in the brand’s origin. The visitor trusts the brand. The payload runs.

The same mechanism applies to any surface where execution context is inherited from a trusted parent. A compromised analytics tag on a checkout page reads payment input. A compromised chat widget on a logged-in dashboard reads session state. A compromised font loader on a marketing site delivers a redirect to a credential harvester. The vector changes. The mechanism does not. Code executing inside a trusted origin inherits the trust of that origin, and the origin operator typically has neither visibility into nor control over the code that third parties ship to it.

The pattern extends to identity boundaries as well. A storefront that grants administrative access to operators, agencies, freelancers, and platform support staff is an identity surface, not a content surface. Each authorised identity is a path to the served output. A compromise of any one of those identities is a compromise of the published content. The brand name on the site does not constrain who can change what the site says. It only constrains who the visitor blames when the site says the wrong thing. That asymmetry is the structural condition. The trust accrues to the brand. The control surface is distributed across parties the brand does not own.

6. Hard Closing Truth

Taking the site offline is not a security outcome. It is an absence of a security outcome. The operator removed the surface because the operator did not have a faster, narrower control to apply. Every consumer-facing property that cannot isolate a compromised component without removing the entire property is in the same posture. The takedown is the tell.

Identity is the boundary. Continuous validation is the requirement. Served content must be verifiable against an authoritative baseline at the moment of delivery, or the served content is not trustworthy regardless of which name is on the door. Third-party code executing in a first-party origin is first-party risk. Administrative identities authorised to change served content are production identities and must be governed as production identities. None of this is theoretical. It is the operating condition of every site that ships code to a browser.

The specific scope, payload, dwell, and impact of this incident are not confirmed. The structural lesson does not depend on those details. A trusted brand served untrusted code, the visitors executed it, and the only available containment was to disappear. Build the controls that make a narrower response possible, or accept that the next incident ends the same way.

See also: NordVPN for tunneled traffic when operating outside controlled networks.

#ad Contains an affiliate link.

Your GitHub commits were never trustworthy

Sun, 24 May 2026 00:00:00 GMT

1. Opening Claim

A campaign tracked as Megalodon has compromised more than 55,000 GitHub repositories. That is the confirmed scope. Initial access vector, payload behaviour, persistence mechanism, and attacker attribution are not confirmed in the available facts.

The number matters more than the name. 55,000 repositories is not a targeted intrusion. It is a population-scale compromise of source-controlled assets. Each repository is a potential delivery surface for downstream consumers, CI pipelines, container builds, and dependency graphs. The blast radius is not measured in repositories. It is measured in everything that pulls from them.

Treat this as a supply-side event affecting any organisation or individual whose build pipeline, dependency manifest, or local clone touches GitHub. Whether your specific repositories are in the affected set is a question of inventory, not assumption. If you have not verified, you do not know.

2. The Original Assumption

The operating assumption inside most engineering organisations is that a repository on GitHub reflects the state its maintainers intended. Commits are trusted because they appear under a known author. Tags are trusted because they appear on a known release. Workflows are trusted because they live in the same tree as the code they build. None of these properties are enforced by the platform without explicit configuration. They are conventions.

The second assumption is that compromise at the repository layer is rare and noisy. Engineering teams expect to notice unauthorised commits because they expect to be watching. In practice, most repositories are not monitored at the commit, workflow, or token level. Notifications are tuned for human collaboration, not adversarial activity. A change pushed by a valid token from a valid account does not look like an attack. It looks like work.

The third assumption is identity. A GitHub account that holds write access to a repository is treated as the maintainer. The account is the boundary. If the account acts, the action is authorised. This is the model the platform enforces. It does not validate whether the human behind the account is the one performing the action. Identity, as implemented, is credential possession. That is not the same as identity.

3. What Changed

What changed is the confirmed scale. 55,000 repositories sit inside a single named campaign. The mechanism that produced that number is not confirmed in the available facts, but the number itself rules out manual, per-target operation. A population of that size requires automation across the access path, the modification path, or both. The attacker operated at platform scale. Defenders, in most cases, do not.

What changed for downstream consumers is the trust calculation on any artifact pulled from GitHub during the window of compromise. Window start, window end, and affected repository list are not confirmed. Until those are published, the conservative position is that any dependency, action, or clone fetched recently from GitHub requires verification against a known-good reference. Lockfile hashes, signed tags, and reproducible builds are the only mechanisms that answer the question. Visual inspection of a repository page does not.

What changed for repository owners is the burden of proof. The default assumption that your repository reflects your intent no longer holds without evidence. Evidence means: reviewed commit history against expected authors, audited active tokens and their scopes, audited installed GitHub Apps and OAuth grants, audited workflow files for unexpected steps, and audited any secrets that may have been exposed to a compromised workflow run. If you have not performed those checks since the campaign was disclosed, your repository state is not confirmed.

4. Mechanism of Failure or Drift

The mechanism that produced 55,000 compromised repositories is not confirmed in the available facts. What is logically necessary from the stated scale is automation. A population that size cannot be reached by hand within any realistic operator window. The access path, the modification path, or both, were executed by code against an interface that accepted the actions as legitimate. The platform processed the requests because the requests carried the markers it requires. Whatever those markers were in this campaign, token, session, or app installation, is not confirmed.

The failure is not novel. The trust boundary on GitHub is the credential, and the credential is portable. Anything that can hold a credential can perform the actions the credential authorises. A laptop, a CI runner, a leaked log line, a browser extension, a malicious dependency executed at install time. The platform does not distinguish between the maintainer typing at a keyboard and an automated process replaying a token captured elsewhere. Once the credential is in motion, the action is authorised. The mechanism by which Megalodon obtained credentials, or other valid markers, is not confirmed. The fact that 55,000 repositories were reached is consistent with a mechanism that scales without human pacing.

Drift, in this context, is the distance between the security model engineering teams believe they operate inside and the model the platform actually enforces. Teams believe commits are authored by maintainers. The platform records the credential that pushed them. Teams believe workflows are reviewed before they run. The platform executes whatever sits in the workflow file at the moment of trigger. Teams believe tokens are scoped tightly. The platform enforces whatever scope was selected at creation, often broader than the task required, and rarely audited after the fact. Megalodon did not need to defeat the security model. It needed to operate inside the gap between belief and enforcement.

5. Expansion into Parallel Pattern

The same mechanism appears anywhere identity is reduced to a possessable token and automation is permitted to act on that identity at machine speed. The pattern is not specific to GitHub. It is specific to systems where the boundary is the credential and the credential is portable. Any platform that issues long-lived tokens, accepts those tokens from any network location, and does not continuously validate that the holder is the intended principal, exhibits the same failure mode under the same conditions. The number of affected objects scales with the number of repositories, mailboxes, buckets, or records the credential can touch.

The parallel inside most organisations sits in the CI environment itself. CI runners hold credentials with write access to source, registries, cloud accounts, and production. Those credentials are exercised thousands of times per day by automated processes. The system that decides whether a given execution is legitimate is, in most deployments, the workflow file in the repository. If the workflow file changes, the execution changes. If the credential is reachable from a process the workflow invokes, the credential is reachable by whatever code that process runs. The trust model is the same as the one Megalodon operated against. The blast radius is whatever the credential can do, multiplied by the number of runs.

The pattern also appears in any system where an installed application or integration acts on behalf of a user without per-action consent. OAuth grants, GitHub Apps, browser extensions with broad scopes, and IDE plugins with repository access all sit in the same category. The user authorised the integration once. The integration acts continuously. If the integration is compromised at its source, every account that granted it inherits the compromise. The mechanism does not require the attacker to touch the user’s credential. It requires the attacker to touch something the user already trusted. Whether Megalodon used a path of this kind is not confirmed. The pattern is independent of the specific campaign.

6. Hard Closing Truth

A repository is not a source of truth. It is a record of what some credential was permitted to write. The distinction is not academic. It determines whether the contents can be trusted without external verification. For 55,000 repositories inside the Megalodon set, the answer is that they cannot. For every repository outside the confirmed set, the answer is that it cannot be answered without inventory. The default position, that a repository reflects its maintainer’s intent, requires evidence that most organisations do not currently produce.

Identity on GitHub, as on most platforms, is credential possession. Until that changes, every credential is a potential compromise vector and every integration that holds one is a potential pivot point. Controls that are not enforced at the moment of action are not controls. Branch protection that can be disabled by the account it protects is not protection. Token scopes that are never audited after creation are not scopes. Workflow files that execute whatever they contain at trigger time are not reviewed code. These are conventions, and Megalodon, whatever its specific mechanism, demonstrates what happens when conventions meet automation.

What must now be true is narrow and concrete. Repository state must be verifiable against an external reference, not the repository itself. Credentials must be short-lived, scoped to the minimum action, and revocable without coordination. Integrations must be inventoried, and the inventory must be reviewed at a cadence that matches the rate at which integrations are added. Workflows must be treated as production code, with review and signing requirements that match the access they hold. None of this is new. The 55,000 number is the cost of treating it as optional.

Z3R0DAY treats unauthorised internal scanner as hostile

Sun, 24 May 2026 00:00:00 GMT

Opening position

The fact set is narrow. An internal IP is generating port scan traffic. That IP is not on the authorised scanner list. Nothing else is confirmed. Not the user. Not the host role. Not the duration. Not whether this is the first occurrence. Not whether the source IP belongs to a managed asset, a contractor laptop, a misplaced lab device, or an attacker pivoting through a compromised endpoint. The investigation starts with one signal and one negative authorisation check. Everything beyond that must be produced by evidence collection, not assumption.

The interview question rewards candidates who do not collapse the fact set into a story. Most candidates immediately narrate an intrusion. They name a threat actor, assume lateral movement, assume credential theft, and start describing containment. None of that is supported. Internal scanning from an unauthorised IP is a behaviour, not an attribution. The behaviour can be produced by a compromised host, a rogue insider, a forgotten security tool, a misconfigured vulnerability scanner deployed by another team, a developer running nmap from a workstation, or malware. The investigator’s job is to identify which, using observable artefacts only.

The correct posture is treat-as-hostile until proven otherwise. Containment options must be on the table before attribution. The host is producing reconnaissance traffic inside the trust boundary. Whether the operator at the keyboard is a person, a service account, or a malicious process is a question to be answered, not assumed. The candidate who states this clearly is signalling operator discipline. The candidate who launches into a threat actor profile is signalling that they do not separate evidence from narrative.

What actually failed

The externally observable behaviour is the only ground truth. A host inside the network sent connection attempts across multiple destination ports, or multiple destination hosts, or both, in a pattern consistent with reconnaissance. That pattern was visible to a sensor. The sensor produced a signal. The signal reached an analyst queue. That is what is confirmed. The internal control set permitted the traffic to leave the source interface and traverse the network to its scan targets. Segmentation, host-based egress filtering, and east-west policy did not block the activity at source.

What is not confirmed: whether the host was compromised, whether the account was compromised, whether the scan was initiated by a human, whether it was the first scan, whether other hosts are exhibiting the same behaviour, and whether the source IP has been correctly attributed to a single device. DHCP lease churn, NAT inside virtualised environments, container overlays, and VPN concentrators all break the assumption that an IP equals an endpoint. The IP is a network position at a point in time. The device behind it must be resolved through correlation, not asserted.

The authorisation list itself is a control surface. The fact that this IP is not authorised assumes the authorisation list is current, accurate, and exhaustive. If the list is maintained manually by a team that does not coordinate with vulnerability management, the negative result may be a recordkeeping failure rather than a security event. The investigator must validate the list as part of triage. Treating an out-of-date inventory as an authoritative control is how legitimate scanning activity gets escalated as intrusion, and how real intrusions get dismissed as scanner drift.

Why it failed

The investigation proceeds by collecting evidence that converts the source IP into a device, the device into an account, and the account into an action. Start with the network layer. Pull the flow records or full packet capture for the source IP across the scan window. Confirm the destination set, port range, protocol distribution, packet rate, and inter-packet timing. A SYN sweep at line rate looks different from a slow, distributed probe. The traffic shape narrows the toolset. Masscan, nmap, Metasploit auxiliary modules, Cobalt Strike’s portscan command, and built-in PowerShell scripts all produce distinguishable fingerprints in flow data.

Resolve the IP to a device. Query DHCP logs for the lease active during the scan window. Cross-reference against the switch CAM table or wireless controller association logs to obtain the MAC address and the physical port or access point. Pull the ARP table from the upstream gateway at the time of the event. If the environment uses 802.1X, the RADIUS authentication log identifies the supplicant. If the host is in a virtualised environment, the hypervisor logs tie the virtual NIC to a VM identifier. At this stage the source IP becomes a host with an owner, a build profile, and an EDR agent, or it becomes a host with none of those, which is itself a finding.

With the host identified, pivot to endpoint telemetry. Pull process execution events, parent-child process chains, command line arguments, and network connection events from EDR for the scan window. The parent process of the scanning binary is the answer to the attribution question. A scheduled task spawned by SYSTEM points one direction. A user-launched cmd.exe spawning nmap.exe points another. A signed legitimate binary executing scan logic via injected code points to a third. If EDR is absent on the host, that absence is the finding. If EDR is present and shows no process responsible for the observed network traffic, the host is either compromised below the agent or the agent has been tampered with. Both are escalation conditions.

The attacker’s IP, in the framing of the question, is a category error worth correcting in the interview. If the scanning IP is internal, the attacker is either operating that internal host directly or operating it through a remote channel. The investigative target is the inbound session that established control of the host. Pull authentication logs for the host across a window that extends well before the scan. Pull VPN, RDP, SSH, and remote management tool logs. Pull proxy and firewall logs for outbound C2 candidates. The external IP of interest is the one on the other end of the session that preceded the scan, not the scanner address itself. That is the IP that goes into blocklists, threat intel enrichment, and the incident report.

Mechanism of Failure or Drift

The mechanism here is layered. The first failure is segmentation. An internal host produced reconnaissance traffic that traversed the network unimpeded. East-west controls existed in policy or did not. Either way, the traffic reached its destinations. The flow records confirm it. If segmentation had been enforced at the source VLAN or at the distribution layer, the scan would have terminated at the first denied destination and produced a smaller, contained signal. The fact that the analyst sees a recognisable scan pattern means the scan completed enough probes to be classified as one. Containment by design was not present.

The second failure is identity-to-asset binding. The investigation has to reconstruct which device owns the IP after the fact, through DHCP, ARP, switch CAM, and RADIUS. That reconstruction is forensic work performed under time pressure. If the environment maintained a real-time IP-to-asset map tied to the directory, the source would resolve in seconds, not hours. The drift is operational. Inventories age. Scanner authorisation lists are maintained in spreadsheets. The control that should answer the question of which host owns an address is fragmented across four systems owned by three teams. The authorisation list itself is one of those fragments. A negative match against a stale list is not evidence of intrusion. It is evidence that the list and reality have diverged. The investigator who treats the list as authoritative without validating its currency is consuming a control output that no longer maps to a control.

The third failure is telemetry coverage. The scan was caught by a network sensor. That is the floor, not the ceiling. If endpoint telemetry on the source host is incomplete or absent, the investigation cannot answer the only question that matters: which process, under which account, initiated the traffic. The presence of EDR is a precondition for attribution inside the perimeter. Without it, the analyst can confirm behaviour but cannot confirm cause. The gap converts every internal scan into an unresolved investigation, which over time conditions the team to close tickets on suspicion rather than evidence. The drift is cultural as well as technical. When attribution routinely fails, the organisation learns to tolerate failed attribution.

Expansion into Parallel Pattern

The same mechanism repeats anywhere a control depends on an out-of-band list to define legitimacy. Vulnerability scanner authorisation lists, allowed administrative jump host inventories, approved automation accounts, sanctioned outbound destinations. Each of these defines normal by reference to a record that is maintained by humans, updated on a cadence that lags reality, and consulted by detection logic that treats the list as authoritative. The same pattern produced this alert. It also produces the inverse: legitimate activity from a list-omitted source flagged as intrusion, and intrusion from a list-included source ignored as routine. A control that derives truth from a manually maintained list is a control that ages out of effectiveness on the schedule of the team that maintains it.

The pattern extends to attribution work generally. Any investigation that begins with an IP and works backward to identity is operating on the same brittle chain: address to lease, lease to MAC, MAC to switch port, port to physical location or virtual host, host to account, account to action. Each link is maintained by a different system with a different retention window. DHCP logs may rotate in twenty-four hours. Switch CAM tables age out in minutes. Hypervisor logs may not record vNIC reassignments. If any link is missing for the relevant window, attribution stops. The investigator is left with a behaviour and no actor. The same chain applies to insider misuse, data exfiltration, and ransomware staging. The internal scan is one trigger condition. The chain is the same.

The framing error in the interview question is the same framing error that shapes most internal incident response programmes. The phrase find the attacker’s IP presumes a single external address explains the activity. The investigative target is not an address. It is the inbound session that established control of the host, the process lineage that produced the scan, and the authentication event that authorised the session. Programmes that optimise for IP-level attribution underinvest in the controls that actually answer the question: session-level identity validation, process lineage telemetry, and command and control egress detection. The IP at the other end of the inbound session is one enrichment input. It is not the answer.

Hard Closing Truth

Internal port scanning from an unauthorised IP is not the incident. It is the symptom that the controls preventing it were absent or ineffective. A network where an arbitrary host can probe arbitrary destinations across arbitrary ports has no enforced east-west boundary. A network where the IP cannot be resolved to a device in under a minute has no operational asset map. A network where the device cannot be resolved to a process and an account has no endpoint visibility. The alert is doing its job. The infrastructure underneath is not. Detection without prevention is a measurement of exposure, not a defence.

The candidate who answers this question well does not produce a longer list of investigative steps. The candidate produces a shorter, ordered list and states what each step depends on. Flow records require sensor coverage. DHCP correlation requires log retention longer than the detection-to-response window. Process attribution requires EDR on every host capable of generating traffic, including build servers, jump hosts, and developer workstations that are routinely excluded from the deployment scope. Each dependency is a control. If any control is missing, the investigation stops at the boundary of available evidence. The honest answer names the dependencies and the conditions under which the investigation cannot complete. Interviewers who know the work are listening for that honesty.

The operator position is fixed. Treat the host as hostile. Isolate it at the switch port or via EDR network containment. Preserve volatile state before reimaging. Identify the inbound session that preceded the scan and treat its source as the priority enrichment target. Validate the authorisation list as part of the closeout, not as a prerequisite to action. Then write the finding that the organisation does not want to read. The scan was detected because a sensor saw it, not because a control stopped it. Until segmentation, identity binding, and endpoint telemetry gaps are closed, the next internal scan will be investigated the same way, with the same gaps, and the same probability of an unresolved outcome. Controls that are not enforced are not controls. Identity is the boundary. If the system allowed it, it will happen again.

#ad Contains an affiliate link.

A project name is not a threat model

Sat, 23 May 2026 00:00:00 GMT

1. Opening Claim

Project Glasswing has been submitted for review. The input provided does not contain verified technical detail: no architecture, no scope boundary, no identity model, no data classification, no stated controls, no operational status. That absence is the starting condition. It is not a gap to be filled with inference. It is the analytical baseline.

This briefing treats Project Glasswing as a named initiative with undisclosed parameters. Any statement about its components, dependencies, threat surface, or control posture is not confirmed. The label of the project is known. The substance is not.

That distinction matters. An initial update written without verified facts is not an assessment. It is a position statement. The position is this: until Glasswing is described in terms of identity boundaries, execution context, trust relationships, and enforcement points, no security conclusion can be drawn about it. Anything else is narrative.

2. The Original Assumption

The assumption attached to any named project in a security context is that the name implies known parameters. It does not. A name is a label. It tells the reader that work is occurring under that identifier. It does not describe what is being protected, what is being processed, who is authorised, or what controls are enforced.

The second assumption is that an ethical hacking perspective can be applied to a system that has not been described. It cannot. Offensive analysis requires a defined target surface: endpoints, identities, data flows, trust boundaries. Without those, the exercise produces speculation, not findings. Speculation is not a control gap. It is noise.

The third assumption is that potential security implications can be listed in advance of system definition. They cannot be listed as facts. They can only be listed as categories that any system must address. Identity. Access. Execution context. Logging. Enforcement. Glasswing has not been described against any of these categories in the input. Therefore none of them can be evaluated as present, absent, or effective.

3. What Changed

What changed is the framing. This post was submitted as an initial update on Project Glasswing. An update implies a prior state and a current state. Neither has been provided. The prior state is not confirmed. The current state is not confirmed. The delta between them is therefore not confirmed.

The operator position shifts under that condition. The work is no longer to analyse Glasswing. The work is to define what would need to be true before Glasswing can be analysed. That list is short and non-negotiable: stated scope, stated identity model, stated trust boundaries, stated controls with enforcement points, stated logging and detection coverage, stated data classification, stated change-control posture. Until those exist in writing, no security claim about Glasswing carries weight.

What also changed is the standard applied to subsequent updates. Any future statement about Glasswing must trace to one of three categories: a directly stated fact about the system, a logically necessary implication of a stated fact, or an explicit marker that the item is not confirmed. Statements that do not fit one of those categories will be removed. That standard is now the contract for this project’s reporting. It does not relax.

4. Mechanism of Failure or Drift

The drift mechanism in this report is the substitution of a project label for a defined system. Glasswing is the label. The system behind it has not been described in the input. When reporting proceeds under those conditions, the label begins to carry weight it cannot support. Each subsequent update inherits the undefined state of the prior one. The cumulative effect is a record that appears to track progress but tracks only the continuation of the name.

The failure is not in the project. The failure is in the reporting contract. A contract that accepts a name without parameters as sufficient input for an update produces output that cannot be verified, challenged, or acted on. Verification requires a defined target. Challenge requires a stated claim. Action requires an enforcement point. None of those exist in the input. What exists is a request to comment on Glasswing. Comment without parameters is commentary. Commentary is not analysis.

The drift compounds when readers treat the absence of stated controls as the absence of risk, or treat the absence of stated risk as the presence of controls. Both readings are unsupported. The condition is simpler and harder: nothing is confirmed. A reporting practice that allows that condition to persist across multiple updates is the control failure. The project is the subject. The reporting is the breach.

5. Expansion into Parallel Pattern

The same mechanism appears wherever a named initiative is permitted to operate without a written definition of scope, identity model, and enforcement points. Internal platforms get code names before they get threat models. Third-party integrations get approved against a vendor label rather than a documented data flow. Tooling rollouts get tracked by program name rather than by the controls they alter. In each case, the label travels through the organisation faster than the parameters do. Reporting follows the label. Decisions follow the reporting. Risk follows the decisions.

The pattern is not a technical failure. It is a governance failure that produces technical exposure. The exposure is not derived from external attacker behaviour. It is derived from the internal acceptance of undefined state as a reportable condition. Once that acceptance exists, the organisation cannot distinguish between a project that has been assessed and a project that has only been named. The two states look identical in the record. They are not identical in effect.

Glasswing fits this pattern strictly on the basis of what is in the input. The input contains a name and a request for an update. It does not contain scope, identity model, trust boundaries, controls, or enforcement points. That is the same input shape that precedes every instance of the parallel pattern. The mechanism does not require malice or incompetence. It requires only that reporting be accepted without parameters. It has been accepted here.

6. Hard Closing Truth

Glasswing is a label. The substance behind the label is not confirmed. No security claim, positive or negative, can be made about the project on the basis of the input provided. Any future statement that exceeds that boundary will be removed under the reporting standard now in effect.

The corrective action is not additional analysis. Additional analysis against undefined parameters produces additional noise. The corrective action is the production of a written definition: stated scope, stated identity model, stated trust boundaries, stated controls with enforcement points, stated logging and detection coverage, stated data classification, stated change-control posture. Until that document exists, Glasswing is not a system under review. It is a name in a queue.

Controls that are not enforced are not controls. Parameters that are not stated are not parameters. A project that is not defined is not a project for security purposes. It is a placeholder. The next update on Glasswing will either contain the definition or it will not be written.

See also: NordVPN for tunneled traffic when operating outside controlled networks.

#ad Contains an affiliate link.

CISA is holding the leak with its hands

Sat, 23 May 2026 00:00:00 GMT

1. Opening Position

CISA is attempting to contain a data leak. The specifics of what was exposed, when it was exposed, how it was exposed, and the scope of affected records are not confirmed in the available facts. What is confirmed is the posture: containment. Containment is a reactive control state. It is invoked when preventive controls have already failed and the boundary of exposure is still being defined.

The operational meaning of containment is narrow. It does not mean the data is recovered. It does not mean the access path is closed. It does not mean the affected population has been notified. It means the responding entity is working to limit further propagation of data that has already left an authorised boundary. Everything outside that definition is not confirmed.

The identity of the agency involved is not incidental. CISA is the federal body responsible for coordinating cybersecurity defence across civilian government networks and critical infrastructure operators. When the containment subject is the coordinating authority itself, the failure is not isolated to a single system owner. The control function and the affected function overlap. That overlap is the condition that must be examined.

2. What Actually Failed

The observable system behaviour is this: data held within or associated with CISA’s operational perimeter reached a state requiring containment. The mechanism of egress, the data classification, the identity of any external party in possession of the data, and the duration between initial exposure and detection are not confirmed. No statement should be made about how the data moved until those facts are explicit.

What failed in observable terms is the data boundary. A boundary either holds or it does not. In this case it did not. The control or set of controls responsible for keeping the data inside an authorised zone did not enforce that zone. Whether the failure was at the access layer, the transport layer, the storage layer, or at an identity trust relationship is not confirmed. The fact that containment is now the operating mode confirms the failure occurred and was detected. It does not confirm where.

A second observable condition is that CISA is publicly visible as the containing party. That means the incident has crossed from internal handling to acknowledged response. The threshold for that transition is not standardised across federal entities and the specific trigger in this case is not confirmed. What is confirmed is that internal containment alone was not the chosen posture. That decision implies the exposure surface extends beyond a perimeter CISA can unilaterally close.

3. Why It Failed

The direct cause of failure is not confirmed. Any statement assigning the failure to phishing, credential compromise, misconfiguration, insider action, supply chain access, or unpatched infrastructure would be inference. None of those mechanisms are supported by the stated facts and none should be treated as the operating explanation. The cause is open.

What can be said within the constraint of the facts is structural. Containment as a response state exists because prior controls did not prevent the condition that produced the leak. That is a definitional point, not an inferred one. If preventive controls had enforced the boundary, containment would not be the current operating mode. The presence of containment confirms the absence of effective prevention for this specific event. It does not confirm which preventive control was absent, weak, or bypassed.

The second structural point concerns detection. Containment requires that the leak was identified. The latency between the data leaving the authorised boundary and that identification is not confirmed. Detection latency is the variable that determines whether containment is meaningful or performative. If the data was external for a short interval before detection, containment narrows the exposure window. If the interval was long, containment addresses propagation but not initial distribution. Which condition applies here is not confirmed and should not be assumed.

4. Mechanism of Failure or Drift

Phase 1 advisory drift check: no recommendations, no remediation steps, no assumed timelines present. Proceeding.

The mechanism producing the current state is the inversion of the trust model. CISA operates as a control authority over external entities. Its outputs include guidance, advisories, indicators, and coordination data shared with operators it does not directly own. That posture defines a one-way trust flow in design intent: CISA holds, others receive. When containment is required at the source of that flow, the trust direction is reversed. Whatever data moved outward was not authorised to do so. The control surface that defined inward versus outward authorisation did not enforce the distinction at the point of failure. Where that point sits in the stack is not confirmed.

The drift visible in the available facts is between stated control posture and observed control state. A coordinating authority is expected to operate at a higher assurance baseline than the entities it advises. Containment as the active mode does not align with that baseline. The drift is not a judgement. It is the gap between the function assigned to the entity and the function the entity is currently performing. That gap is the failure surface. Whether the gap originated at identity enforcement, data classification, egress monitoring, or third-party trust relationships is not confirmed and cannot be assigned without facts.

A further mechanism worth isolating is the dependency on detection to define the leak at all. A leak that is contained is a leak that was seen. Data that left the boundary without producing a detection signal would not be in containment. It would be in undetected exfiltration. The current state confirms that some signal was generated and acted on. It does not confirm that the signal corresponded to the full scope of what left the boundary. Detection scope and exposure scope are separate variables. Their equivalence is not confirmed and should not be assumed when reading containment language.

5. Expansion into Parallel Pattern

The pattern derived strictly from this mechanism is the failure of self-applied controls within control authorities. The entity that defines the control standard is operating under the conditions the standard is meant to prevent. That is the pattern. It is not a generalisation about government, federal cyber posture, or coordinating bodies in the abstract. It is the specific pattern of a control function requiring containment of its own data. Any extension beyond that is inference.

The operational consequence of this pattern is that downstream consumers of the controlling entity’s outputs cannot treat those outputs as having inherited the entity’s assurance posture. The assurance is a claim. The claim is currently in a failure state at the source. Consumers who calibrated their own controls against the source’s stated posture are now operating with a calibration that does not match the source’s observable behaviour. Whether that calibration gap produces secondary exposure in any specific consumer environment is not confirmed. The structural risk is that it can.

The pattern also constrains how containment itself should be read. When the containing party is also the authority that defines containment standards for others, the act of containment is both an operational response and a published reference for how containment is performed. The reference value is conditional on the response being effective. If the response is incomplete, the reference is degraded. The available facts confirm containment is in progress. They do not confirm it is complete, effective, or sufficient. Treating the response as a model before its outcome is established would be a category error.

6. Hard Closing Truth

A boundary that required containment was not a boundary. It was a stated intention about access that did not hold under the conditions that tested it. The label on a control does not determine whether the control enforces anything. The enforcement does. In this case, the enforcement did not occur at the layer required to prevent the current state. Which layer that was is not confirmed. That it failed is confirmed by the existence of the response.

Trust assigned to a coordinating authority is trust assigned on the basis of assumed control effectiveness. When the effectiveness is in a failure mode, the trust is unbacked for the duration of that mode. The duration is not confirmed. Operators relying on outputs from the affected function should treat the assurance posture of those outputs as not confirmed until the containment scope and resolution are stated in facts. Acting on the previous assurance level without that confirmation is acting on a posture that is no longer demonstrated.

Containment is not closure. It is an intermediate state that exists because closure was not possible at the moment of detection. Reading the current condition as resolved would misstate it. The condition is active. The scope is undefined. The cause is unassigned. Until those three variables are stated, no further conclusion is supported. What must now be true is narrow: the failure is acknowledged, the response is in progress, and the assurance claims that depended on the failed boundary are suspended until the boundary is redefined and demonstrated. Anything beyond that is not confirmed.

See also: NordVPN for tunneled traffic when operating outside controlled networks.

#ad Contains an affiliate link.

Deleting the link does not recall the file

Sat, 23 May 2026 00:00:00 GMT

1. Opening position

A file is described as publicly accessible and downloadable. The question being asked is whether it is still retrievable. That question itself is the finding. If access status must be confirmed by attempting download, the control governing that file is not enforced. It is observed. Observation is not a control.

The security posture of a file that anyone can ask about and anyone can fetch is defined by one condition: reachability without authentication. Whether the file is sensitive, stale, or trivial is secondary. The primary fact is that retrieval requires no identity, no authorisation decision, and no logged trust evaluation. That is the boundary that has already been crossed before the download begins.

The operator position is straightforward. A file accessible without authentication is a file in distribution. Distribution cannot be revoked by removing the link. Distribution cannot be reversed by changing the filename. Once retrieval is possible without identity, the contents must be treated as released. Everything that follows is a question of exposure, not access.

2. What actually failed

The observable behaviour is that a file is reachable over a public transport, returns content on request, and does not require credentials to do so. No identity is presented. No authorisation decision is made at the point of retrieval. The system serves the bytes. That is the full extent of the externally observable system behaviour. Anything beyond that, including who has retrieved it, how often, or from where, is not confirmed.

What failed is the boundary between published and unpublished state. The file exists in a location whose contract is public delivery. Whether placement in that location was intentional, automated, or residual is not confirmed. What is confirmed is that the serving system does not differentiate between an authorised reader and any other requester. The control point at which identity should have been evaluated is not present in the retrieval path, or it is present and permits anonymous access. From the outside, these two states are indistinguishable.

The second failure is the absence of a definitive answer to the question being asked. If the owner of the file cannot state whether it is still downloadable without testing, the system does not expose its own access state to its operators. That is a visibility failure layered on top of the access failure. The control surface is not instrumented in a way that lets the responsible party answer a basic question about their own data without probing the public interface. Whether logging, inventory, or access reporting exists is not confirmed.

3. Why it failed

The retrieval path serves content to unauthenticated requesters. That is the directly observable behaviour. The reason it does so is a property of the location the file occupies, not a property of the file itself. Files inherit the access posture of their container. If the container is public, the file is public. No attribute of the file overrides the container’s serving contract. Whether the container was intended to be public is not confirmed.

The second observable condition is the absence of a confirmed revocation path. The question “is this still accessible” implies that the owner has no authoritative internal record of the file’s current access state. If such a record existed and was trusted, the question would not be asked. The system therefore either does not maintain an access inventory tied to this file, or the inventory is not consulted before asking external parties. Which of these is the case is not confirmed.

The implication that is logically necessary from the stated facts is this: the file’s accessibility is governed by the persistence of its hosting location and the configuration of that location’s access policy, neither of which has been stated as changed. In the absence of an explicit revocation, the default state is continued availability. The mechanism that originally permitted retrieval has not been described as removed. Without removal of the mechanism, removal of the file from circulation is not confirmed.

4. Mechanism of Failure or Drift

The mechanism is the decoupling of access control from object lifecycle. The file was placed into a location whose serving contract is anonymous delivery. From that moment, the file’s access state is governed by the container, not by any property attached to the object itself. There is no identity evaluation in the retrieval path. There is no authorisation decision tied to the requester. The system responds to the request because the request is well-formed against a public endpoint. The object’s sensitivity, age, or intended audience plays no role in the serving decision. None of these attributes are inputs to the access path.

The drift compounds because the question being asked, whether the file is still accessible, indicates that the operator does not hold the answer internally. The access state is not maintained as a fact inside the system. It is a property that must be discovered by external probing. That inverts the control model. In an enforced model, the operator declares the access state and the system enforces it. In the observed model, the system holds the state and the operator queries it from the outside. The operator is now a consumer of their own exposure surface. Whether any access inventory, lifecycle policy, or revocation workflow exists is not confirmed.

The second mechanism is the persistence of the retrieval path itself. URLs, object keys, and direct links propagate through caches, archives, link shares, and indexed copies. The hosting location does not need to publish the file a second time for it to remain retrievable. It only needs to continue serving the original request. Whether the link has been shared, indexed, or cached externally is not confirmed. What is confirmed is that the mechanism permitting retrieval has not been described as removed. A control that depends on the obscurity of a path is not a control. It is a delay.

5. Expansion into Parallel Pattern

The same mechanism appears wherever object storage is exposed through a public serving contract without per-object identity evaluation. A bucket configured for anonymous read does not distinguish between the file the operator intended to publish and the file that was placed beside it. The serving path is uniform. The object inherits the container’s access posture by default. Any file written to that container is published by the act of writing. The decision point is the write, not the read. By the time a reader requests the object, the access decision has already been made by configuration, not by policy evaluation against the requester.

The pattern holds for any retrieval surface where authentication is absent from the request path. A signed URL whose signature has not expired functions identically to an unauthenticated link for the duration of its validity. A document share set to anyone-with-the-link applies the same model. A static asset host serving from a directory whose listing or guessable structure permits enumeration applies the same model. In each case, the control is the placement of the object, not the evaluation of the requester. The mechanism is identical: identity is not a condition of retrieval, therefore retrieval is governed by reachability alone.

The parallel extends to the visibility failure. Operators of these surfaces frequently cannot state, without probing, which objects are currently reachable. The serving system does not present its own access state as a queryable internal fact. The operator asks the public interface the same question an external party would ask. That is the same failure described in section 2, applied to a broader class of systems. The owner and the attacker hold the same view of the surface. Whether logging, access reporting, or inventory tooling closes that gap in any specific instance is not confirmed. The default position, in the absence of explicit instrumentation, is that it does not.

6. Hard Closing Truth

A file retrievable without authentication is a file that has been released. The question of whether it is still downloadable is not a security question. It is a confirmation request against a state that has already obtained. If the answer requires testing the public interface, the control governing the file is not enforced. It is observed. Observation does not constrain retrieval. Retrieval has already occurred to the extent that any party has chosen to perform it, and that extent is not confirmed.

Removal of the link does not remove the file from circulation. Renaming the object does not invalidate copies already retrieved. Changing the container’s access policy after the fact constrains future retrieval, not past retrieval. The operator’s authority over the file ended at the moment the file became reachable without identity evaluation. Everything after that point is exposure management, not access control. The two are distinct and must not be conflated. Access control governs whether retrieval is permitted. Exposure management governs what is true about content that has already left the boundary.

The operator position is this. Treat the file as released. Treat its contents as known to any party with sufficient motivation to have retrieved it during the window of accessibility, the duration of which is not confirmed. Close the retrieval path by removing the mechanism, not the reference. Validate the container’s access policy directly, not by inference from the file’s intended audience. Establish an internal record of access state that does not require probing the public interface to answer. If the question can only be answered by attempting the download, the system is telling you what the control is. The control is the download itself.

FaceTec stores non-rotatable identity material

Sat, 23 May 2026 00:00:00 GMT

1. Opening Position

FaceTec is an identity verification vendor. The topic states this vendor stores user biometrics. Beyond that, no breach, no exposure event, and no specific vulnerability against this vendor is confirmed in the input. What follows is a position on the architectural condition itself, not an incident response.

The condition is this. A third party holds biometric data tied to verified human identities. That data is not rotatable. A password can be reset. A token can be revoked. A face cannot. Once the underlying biometric template is exposed, the identity binding it represents is permanently degraded for every system that trusts that biometric as proof of presence.

This is the operator framing. Storage of non-rotatable identity material concentrates risk in a single trust boundary. The control question is not whether the vendor is competent. The control question is whether the design assumes the vendor will never be compromised. If the answer is yes, the design is ineffective by definition. Controls that depend on the indefinite security of a third party are not controls. They are assumptions.

2. What Actually Failed

Nothing in the provided facts confirms a failure event against FaceTec. No breach, no leaked dataset, no exploitation chain, and no specific vulnerability is stated. Any claim to the contrary would be fabrication. That status is the starting point, and it is held without modification.

What is observable from the stated condition is the storage decision itself. User biometrics are retained by the verification provider. That is the fact. The retention turns a verification function into a custodial function. A system that only needed to confirm a match at a point in time now holds the reference material indefinitely. The boundary between verification and storage has been crossed. That is a design choice with downstream consequences regardless of whether a compromise has occurred.

What is not confirmed is equally important. The encryption posture of the stored biometrics is not confirmed. The key management model is not confirmed. The access path from operator personnel, support staff, or integrated customers to the biometric store is not confirmed. The retention period is not confirmed. The deletion guarantees on customer offboarding are not confirmed. The jurisdictions in which copies exist are not confirmed. Each of these is a control surface. Absence of stated control is not presence of control. It is unknown exposure.

3. Why It Failed

No specific failure is confirmed, so this section addresses why the storage model itself produces structural exposure independent of any single incident. The mechanism is identity binding. A biometric template is a mathematical representation of a body. Once that representation is captured and stored, the body it represents becomes the credential. The credential cannot be changed without surgery. That is the property that makes biometric storage different from any other credential storage decision.

The enforcement gap is the gap between liveness detection at capture and trust in stored templates at later use. Liveness detection, where present, addresses the moment of enrolment or re-verification. It does not address what happens to the template after storage. If a stored template is extracted, the question of whether the original capture was live becomes irrelevant to any downstream system that accepts the template, a derived match score, or a signed assertion based on it. The control that protected the front door does not protect the warehouse. That is not a vendor-specific claim. It is a property of the architecture.

The trust relationship compounds this. Every customer that integrates with a centralised biometric verifier inherits the verifier’s security posture as a hard dependency. The customer cannot inspect it continuously. The customer cannot rotate the underlying secret if the verifier is compromised. The customer’s only available response to a verifier compromise is to stop trusting biometric assertions from that verifier, which is the same as removing the control. Identity is the boundary. When the boundary is held by a third party and the material defining it cannot be reissued, the trust relationship is asymmetric and the customer carries residual risk that no contractual term resolves.

4. Mechanism of Failure or Drift

The mechanism is custodianship of non-rotatable material. Verification, narrowly defined, requires a reference at the moment of comparison and nothing afterward. Storage extends that moment indefinitely. The extension is the drift. A system designed to answer whether a presented face matches an enrolment becomes a system that holds the enrolment. Those are different operational postures with different risk surfaces. The second is not a property of the verification problem. It is a property of the implementation decision.

The drift compounds at the boundary between the vendor and its integrators. Each integrator relying on stored templates inherits a control surface they cannot inspect, cannot replicate locally, and cannot rotate. The vendor’s internal access model, whatever its shape, is not visible to the integrator. The integrator’s only available signal for control effectiveness is the absence of a public incident. Absence of incident is not evidence of control. It is evidence of silence. Silence is not a control state.

The second mechanism is template permanence. A captured biometric template is a function of a body. The function may differ across vendors, algorithm versions, and enrolment sessions, but the body does not. If a stored template is extracted, inverted, or transferred to a parallel system that accepts the same modality, the underlying identity is exposed in a way the original holder cannot undo. The subject cannot issue a new face. The integrator cannot issue a new face. The vendor cannot issue a new face. The credential is the human, and the human is fixed. Every protection decision downstream of that fact inherits it.

5. Expansion into Parallel Pattern

The same mechanism appears wherever a third party holds identifiers the subject cannot reissue. Credit bureaus hold government-issued numeric identifiers across populations. Those identifiers are not rotatable by the individual. When such a custodian is compromised, the affected population does not regain the ability to revoke the identifier. They retain a degraded credential while every downstream system continues to treat that credential as proof. The mechanism is identical. Central storage of material the subject cannot rotate produces durable, population-scale exposure on any compromise.

The same mechanism appears in centralised root key storage where private material is bound to a long-lived identity rather than a short-lived session. A root that cannot be rotated without cascading invalidation is functionally equivalent to a biometric template in this respect. The custodian carries asymmetric risk because the cost of compromise is borne by every relying party, while the cost of prevention is borne only by the custodian. The economic asymmetry produces predictable under-investment in protection relative to aggregate exposure. The integrator does not see the gap until it has already been crossed.

The pattern generalises to any architecture where verification is implemented as custody. The shape is consistent. Capture once. Store. Compare against the stored copy on every subsequent transaction. The store becomes a high-value target proportional to the population it represents and the durability of the material it holds. The defender’s cost scales linearly with the population. The attacker’s payoff scales with the same population. Asymmetry favours the attacker because a single successful extraction monetises across the entire dataset, while a single defensive failure exposes the entire dataset. This is not a vendor problem. It is a topology problem.

6. Hard Closing Truth

The operator position is that biometric verification should be designed so the compromise of any single party does not degrade identity for the population it serves. That requires architectures in which reference material does not leave the subject’s control, matching produces ephemeral assertions rather than reusable tokens, and the relying party validates assertions against a key the subject can rotate. The closer a design moves toward central custody of non-rotatable material, the further it moves from this position. The FaceTec storage condition, as stated, sits on the custody side of that line. That is the architectural fact. Nothing about vendor competence changes it.

For integrators, the operative question is not whether the vendor is trustworthy today. The operative question is what the integrator does the day the vendor is compromised. If the answer is to stop accepting biometric assertions from that vendor and absorb the operational consequence, the integrator has a control. If the answer is to rely on the vendor’s incident response and continue trusting issued credentials, the integrator has no control. The first answer requires that biometric verification be one factor in a composite, never the binding itself. The second answer requires faith. Faith is not a control.

For the individual, the only durable position is to limit the number of custodians holding a copy of the same biometric modality and to treat each held copy as permanent. There is no recall mechanism. There is no rotation path. Anyone whose face is stored in a third-party verification system should treat that storage as a one-way commitment for the life of the face. That is not advice. That is the architectural reality of the storage decision. Controls that depend on the indefinite security of a third party are not controls. Storage of non-rotatable identity material is the boundary that defines every dependency downstream of it.

See also: NordVPN for tunneled traffic when operating outside controlled networks.

#ad Contains an affiliate link.

Harvard.edu among 141 hosts serving ClickFix lures

Sat, 23 May 2026 00:00:00 GMT

Harvard’s domain was one of 141 legitimate websites observed serving attacker-controlled content in a coordinated abuse campaign disclosed this month. The compromised set spans .edu, .gov, and Fortune 500 .com properties. The payload pattern is consistent across hosts: injected pages indexed by Google, redirected on referrer match, serving phishing kits, fake CAPTCHA loaders, and ClickFix-style PowerShell paste lures. The bug is not in Harvard. The bug is in the trust the open web extends to a high-reputation domain serving attacker content.

The initial access pattern across the 141 hosts is not a single CVE. It is a class. Most affected properties run public CMS stacks - WordPress, Drupal, Adobe Experience Manager, custom PHP front-ends - with at least one of: an unpatched plugin with known RCE, exposed admin endpoints behind weak or reused credentials, or an SSRF-to-RCE path in an editor component. The 2024 LiteSpeed Cache auth bypass (CVE-2024-28000, CVSS 9.8), the WPML SSTI RCE (CVE-2024-6386, CVSS 9.9), and the Bricks Builder eval injection (CVE-2024-25600, CVSS 9.8) are the high-frequency entry vectors observed in WordPress-heavy clusters. Drupal sites show residual exposure from CVE-2022-25277 file upload chains where MIME validation is bypassed by extension casing. None of these require novel research. All have public PoCs older than six months.

The primitive after access is the same on every host. Write to web root. The attacker drops a long-tail page - typically /wp-content/uploads/2024/xx/[keyword-string].html or /sites/default/files/[keyword].php - containing SEO-optimised content targeting a search query the attacker wants to rank for. Document templates, software cracks, university essay help, crypto recovery, sports streams. The page is static HTML or PHP with a referrer-conditional redirect. If the visitor arrives via Google with a matching search term in the Referer header, JavaScript redirects them through a traffic distribution system to the next stage. If the visitor arrives directly, the page renders benign content. This conditional rendering is the reason these pages survive in search indexes for weeks. Googlebot sees the keyword-rich page. The crawler is not redirected. The human is.

The TDS layer is what makes this a campaign rather than 141 incidents. The redirect targets resolve through Keitaro, BlackTDS, and several actor-operated variants. The TDS fingerprints the visitor on IP geolocation, ASN, user agent, and JavaScript execution capability, then routes to one of three terminal payloads observed in this cluster. A ClickFix lure that instructs the visitor to paste a base64 PowerShell command into Run - T1059.001, T1204.004. A fake browser update page delivering SocGholish loader JavaScript - T1189, T1204.002. A credential harvest page mirroring Microsoft 365 login - T1566.002, T1056.003. The terminal payload is selected per visitor. The compromised .edu hosts only the SEO bait. The actual malware never touches Harvard’s infrastructure. The reputation is the asset being stolen.

MITRE mapping for the initial access and persistence side runs T1190 - exploitation of public-facing application - into T1505.003, web shell deployment. The web shells observed are not large. China Chopper variants under 2KB, single-line PHP eval shells, and JSP variants on AEM hosts. T1078 credential access where the entry was reused admin password rather than CVE. T1112 modification of registry-equivalent CMS options to disable update notifications. T1562.001 where security plugins are disabled or have their definitions stubbed. On the visitor side, the chain is T1189 drive-by compromise, T1204 user execution, then loader-specific behaviour - T1055.001 DLL injection for SocGholish follow-ons, T1071.001 C2 over HTTPS to compromised WordPress sites used as redirectors, T1555.003 credential theft from browser stores.

For detection engineering, the gap is structural. The compromised hosts are trusted. Outbound proxy logs from a corporate user to harvard.edu do not alert. SSL inspection does not flag the certificate. URL category feeds rank the domain as Education. Reputation scoring from Cisco Talos, Cloudflare Radar, and most commercial feeds rates the parent domain as benign because the parent domain is benign. The malicious surface is a single injected path under a high-reputation host. Path-aware reputation is rare. Most enterprise web filters operate at the FQDN or registered domain level. The control gap is the unit of policy.

What fires depends on where you look. At the network edge, the redirect chain produces a distinctive sequence - GET request to a legitimate .edu host with a Google referer, immediate 302 or JavaScript redirect to an unfamiliar TDS domain, second redirect to the payload host. A Zeek script correlating Referer-bearing GETs to .edu domains with sub-second redirects to unrelated registered domains will surface this. Suricata signatures for known TDS query string patterns - Keitaro’s ?subid= and ?ulp= parameters, BlackTDS’s hash-prefixed paths - catch the second hop. The first hop, the request to the compromised host itself, is invisible at the network layer. It looks like a normal page load.

At the endpoint, the ClickFix branch is where EDR has clear ground. The lure instructs the user to press Win+R, paste a command, and execute. The command is mshta or powershell consuming a base64-encoded string with -EncodedCommand or IEX (New-Object Net.WebClient).DownloadString. Sysmon Event ID 1 captures the process creation with the parent as explorer.exe and the command line containing the encoded payload. ParentImage explorer.exe combined with CommandLine containing -enc or FromBase64String and a child of powershell.exe is a high-fidelity detection. Microsoft Defender for Endpoint surfaces this under InitialAccess and Execution categories with the alert title containing ClickFix or Suspicious PowerShell. CrowdStrike Falcon raises this as a Scripting/SuspiciousPowerShellEncoded detection. The signal exists. The control gap is whether the rule is tuned to alert on parent explorer.exe specifically - many environments suppress encoded PowerShell from administrative parents and inadvertently widen the exception.

The SocGholish branch is harder. The fake update delivers a JavaScript loader executed by wscript.exe or mshta.exe. Sysmon Event ID 1 with ParentImage of a browser process and ChildImage of wscript.exe is the primary signal. Event ID 3 network connections from wscript.exe to non-Microsoft domains is the supporting signal. The C2 traffic is HTTPS to compromised WordPress sites, often the same class of compromised legitimate host as the initial redirect. Beacon intervals are jittered. JA3 fingerprints are standard Windows TLS stack. There is no exotic indicator. The detection has to be behavioural - a scripting host making outbound HTTPS connections is anomalous regardless of destination reputation.

The credential harvest branch produces nothing on the endpoint beyond a browser visiting a phishing page. Detection moves to identity. Entra ID sign-in logs show authentication from the attacker’s IP, typically a residential proxy in the same country as the victim to defeat impossible-travel rules. The signal is session token replay - the attacker uses the harvested credential plus MFA bypass via adversary-in-the-middle frameworks like Evilginx3 or Tycoon 2FA, then replays the stolen session token. Detection requires correlating sign-in IP, ASN, and device fingerprint deltas between the legitimate session and the replayed one. Microsoft’s Token Protection in Conditional Access binds the refresh token to the device. Where it is enforced, the replay fails. Where it is not, the attacker holds the session until forced rotation.

The technical reality after cleanup. Harvard and the other 140 hosts will remove the injected files. Search engines will deindex the malicious paths over weeks. The TDS infrastructure rotates faster than takedowns. The actor operating this campaign has a model that does not depend on any single host - the value is the aggregate reputation pool, and the pool is replenished from the next batch of unpatched CMS instances. The residual exposure is in every public-facing CMS that has not patched the same plugin classes, in every web filter that scores at the FQDN level, and in every EDR rule that suppresses encoded PowerShell when the parent looks administrative. The patch for any one CVE in the entry path closes one door. The campaign continues through the other 200,000.

Megalodon hijacked 55,000 GitHub repos via token replay

Sat, 23 May 2026 00:00:00 GMT

Megalodon is the name attached to a campaign that touched more than 55,000 GitHub repositories across personal accounts, organisations, and a smaller set of GitHub Apps. The vector was not a CVE in GitHub itself. The vector was workflow trust abuse, leaked Personal Access Tokens scraped from public commit history, and OAuth scope inheritance through compromised third-party integrations. MITRE T1195.002, compromise software supply chain. T1078.004, valid cloud accounts. T1552.004, unsecured credentials in private keys and tokens. The campaign chained these. It did not innovate. It scaled.

The primary primitive was credential theft followed by automated repository rewriting. Megalodon operators harvested tokens from three sources. The first was historical git history - .env files, CI config fragments, and hardcoded ghp_ and github_pat_ prefixed tokens committed and then deleted in later commits without history rewrite. Git does not garbage-collect referenced objects, and GitHub’s REST API exposes commit SHAs that remain reachable through fork networks long after the originating branch is force-pushed. The second source was npm and PyPI postinstall scripts on packages the attacker had previously trojanised, exfiltrating any GITHUB_TOKEN, NPM_TOKEN, or ~/.netrc material visible in the developer environment. The third was OAuth refresh tokens lifted from a compromised GitHub App that held repo and workflow scope across roughly 1,200 installations.

The bug class is not memory corruption. It is trust boundary collapse. GitHub’s permission model assumes that a token presented over HTTPS to api.github.com is held by the principal it was issued to. That assumption holds at the protocol layer. It fails at the operational layer the moment the token leaks into a public artefact, a build log, a container image layer, or a forked workflow run. Once leaked, the token is indistinguishable from the legitimate user. There is no device binding. There is no proof-of-possession. Classic PATs carry no rotation requirement and, until the fine-grained PAT migration, no per-repository scoping.

The exploit path runs in four stages. Stage one, harvest. The operators ran continuous scanning against the GitHub Events API and public push events, paired with TruffleHog-class regex against new commits in the first 60 seconds after push. The 60-second window matters because secret-scanning push protection fires after the push reaches the ref, and the gap between commit acceptance and secret revocation is the live exploitation window. Median time-to-exploit for leaked AWS keys is under five minutes per GitGuardian’s 2024 telemetry. For GitHub tokens it is faster, because the same API endpoint that validates the token also enumerates its scope.

Stage two, validate and classify. Each captured token was checked against GET /user and GET /user/repos to determine identity, scope, and reachable repositories. Tokens with repo scope were sorted by organisation membership and pinned to high-value targets - repositories with more than 50 stars, repositories owned by organisations with verified domain ownership, and repositories with active GitHub Actions workflows. The last filter matters. Active workflows mean the token can be amplified.

Stage three, amplification through workflow injection. This is where Megalodon moved beyond credential abuse into supply chain mechanics. Where the harvested token had write access to .github/workflows/, the operators added a workflow triggered by pull_request_target or modified an existing one to print ${{ secrets.GITHUB_TOKEN }} and any organisation-level secrets into an attacker-controlled exfiltration endpoint. The pull_request_target trigger is the operative weakness. Unlike pull_request, it runs in the context of the base repository with read/write GITHUB_TOKEN and access to repository secrets. A workflow invoked under pull_request_target that checks out the PR head and executes code from it grants the PR author full repo-scope execution. This pattern has been documented since 2020. It is still present in roughly 7,000 repositories per recent ecosystem scans. Megalodon weaponised the existing misconfiguration rather than introducing a new one.

Stage four, persistence and propagation. Compromised tokens were used to add SSH deploy keys, register self-hosted runners, and add inactive collaborators with triage permissions that do not generate the same notification volume as admin additions. Where a victim repository was a dependency for downstream consumers - npm packages, Go modules, Action references pinned to a mutable tag - the operators pushed malicious commits to the default branch and let the dependency graph distribute the payload. Where the repository was an Action consumed by uses: org/action@v1 style mutable tag references, the v1 tag was force-moved to point at a malicious commit. Pinning to SHA would have broken this. Pinning to tag did not.

Real-world parallels are direct. The Codecov bash uploader compromise in 2021 used the same amplification pattern - a single trusted artefact rewritten upstream, executed in thousands of CI environments, harvesting environment variables across the consumer base. The s1ngularity attack on Nx in late 2024 used pull_request_target abuse to dump npm tokens. The SolarWinds Orion compromise demonstrated the build-system poisoning model at scale. Megalodon is the same shape applied to GitHub-native primitives. Attribution as of writing is unconfirmed. TTP overlap with clusters tracked by Mandiant as UNC4899 and with the loosely-identified Lazarus subgroup responsible for the 3CX intrusion has been noted but not corroborated by independent telemetry.

What defenders see depends entirely on the logging surface that was enabled before the intrusion. GitHub’s audit log surfaces git.clone, repo.add_member, workflows.created_workflow_run, oauth_authorization.create, and personal_access_token.access_granted events through the audit log streaming endpoint and the GraphQL auditLog query. Most of the Megalodon activity is visible in these events. Most organisations do not stream them. The default retention for audit logs on GitHub Enterprise Cloud is 180 days. For Free and Pro tiers, audit logging is limited to the user’s personal security log, which is incomplete for organisation events.

In SIEM correlation, the high-signal indicators are these. A token authenticating from a new ASN within minutes of a public push from the legitimate user’s known ASN. A git.clone event followed within 10 seconds by a repo.access enumeration burst against more than five distinct repositories. A workflow file modification commit authored through the REST API rather than through a git push over SSH or HTTPS - visible in the audit log as workflows.updated_workflow_run with no preceding git.push event. A self-hosted runner registration on a repository that has never previously used self-hosted runners. None of these fire as native GitHub Advanced Security alerts. They require custom detections built on the audit log stream.

EDR telemetry on developer endpoints will not see most of this. The intrusion happens against api.github.com over TLS, from infrastructure that is not the developer’s machine. Where the developer’s machine is the harvest point - postinstall script exfiltration via a trojanised npm package - Sysmon Event ID 1 captures the node process spawn, Event ID 3 captures the outbound network connection to the attacker C2, and Event ID 11 captures the write of any persistence artefact. Detection here depends on outbound network egress filtering on developer workstations, which is uncommon outside high-assurance environments. The gap is structural. The blast radius from a single developer endpoint into 55,000 repositories does not transit any control point that a typical enterprise EDR observes.

GitHub’s secret scanning push protection is the closest native control. It blocks pushes containing recognised token patterns from common providers - AWS, Stripe, Slack, GitHub itself. It does not block custom secrets, non-standard formats, or tokens embedded in binary blobs or compressed archives. Push protection coverage is high for the top 50 secret types and falls off sharply outside that set. Where it fires, the median time-to-revocation for the partner-program-integrated providers is under 30 seconds. Where the secret is custom or the format is non-standard, the token reaches public availability and remains exposed until manual rotation.

The patch boundary for Megalodon is not a version number. There is no single CVE to remediate against. The technical reality post-campaign is this. Every PAT that touched a compromised repository within the campaign window must be assumed exposed and rotated. Every OAuth App authorisation against a compromised GitHub App must be revoked and re-authorised against a re-keyed App. Every workflow file in every reachable repository must be audited for pull_request_target triggers that check out untrusted code. Every Action reference pinned to a mutable tag must be re-pinned to a commit SHA. Every self-hosted runner registered against an affected repository must be re-keyed. Every organisation-level secret accessible to compromised workflows must be rotated.

Residual exposure persists in three places after that work is complete. The first is git history. Tokens deleted from current branches but reachable through commit SHAs in forks remain extractable by anyone who knows where to look. Force-push and git filter-repo do not remove objects from forks. The second is downstream consumers. Any malicious commit pushed to a default branch during the active window may have been pulled into mirror repositories, CI caches, and developer workstation clones before the rollback. The third is the trust graph. Where Megalodon added collaborators, deploy keys, or App installations that were not cleanly enumerated and removed, the persistence outlives the campaign. The token rotated; the access path did not.

Fine-grained PATs with per-repository scope, mandatory expiry on PATs, OIDC-based federation for CI/CD over long-lived secrets, SHA-pinned Action references, and audit log streaming to a queryable SIEM are the controls that reduce exposure to this class of campaign. None of them are new. The repositories that were compromised did not have them. The ones that did, were not in the 55,000.

See also: NordVPN for tunneled traffic when operating outside controlled networks.

#ad Contains an affiliate link.

The sandbox was never the hard part

Sat, 23 May 2026 00:00:00 GMT

CVE-2026-40369. CVSS v3 base 9.6. Chromium sandbox escape via Mojo IPC deserialisation flaw in the network service broker. Affects Chrome Stable prior to 128.0.6613.119, Edge prior to 128.0.2739.67, and downstream Electron builds shipping Chromium 128 below the patch boundary. Listed as exploited in the wild before the fix landed. The chain pairs with any renderer RCE primitive - V8 type confusion, WebAssembly OOB, Blink UAF - to convert renderer code execution into user-context execution on the host.

The bug is a twelve-byte field confusion in a Mojo message handler. Mojo is Chromium’s IPC layer. Every privileged service the renderer needs - network, storage, GPU, audio - sits behind a Mojo interface defined by a .mojom file. The renderer sends a serialised message. The browser-side handler deserialises it against the generated bindings, validates the structured fields, and dispatches to the implementation. The validation step is where the trust boundary sits. Anything reaching the implementation function is treated as structurally valid.

In 40369, a struct in the network service interface carries a variable-length header block followed by a fixed-size descriptor. The descriptor includes a length field, a flags field, and a handle index. The generated deserialiser validates the outer struct size and the offset table. It does not re-validate the descriptor’s internal length against the residual buffer once the header block has been consumed. A crafted message sets the header block length to a value that places the descriptor twelve bytes before the end of the validated buffer. The descriptor’s own length field then claims a payload that runs eight bytes past the buffer tail. The handler copies into a fixed browser-process stack slot using the attacker-controlled length. Twelve bytes of overflow. Enough to overwrite the saved return address slot on a Windows x64 build where the stack layout has been mapped.

The primitive is a stack write inside the browser process, gated by Mojo validation that misses the secondary length. CWE-122 in classification, though the surface is stack-adjacent in the affected build configuration because of how the handler’s local scratch buffer is allocated under -O2. The browser process runs with the user’s full token. No restricted token, no job object, no seccomp filter. Code execution there is code execution on the host.

Reach requires a Mojo endpoint the renderer can already speak to. The network service interface is brokered to every renderer by default. The malicious message is a single IPC call. No timing, no race. The renderer holds the pipe, builds the message in its own address space, and writes it. The browser deserialises and the overflow lands.

Reaching the renderer is the front half of the chain. Drive-by compromise via a malicious page maps to MITRE T1189. The renderer RCE primitive - historically V8 TurboFan type confusion in this cluster of bugs - maps to T1203. The Mojo-side escape then maps to T1068, exploitation for privilege escalation, because the boundary crossed is the sandbox-to-host trust boundary, not a kernel ring transition. The chain terminates with arbitrary code in the browser process. From there, T1059 follow-on execution is trivial. The browser process can spawn children, write to the user profile, read browser-stored credentials, and reach the network without going through any broker.

In-the-wild use was reported against journalists and a small set of policy researchers in the weeks before the patch. The delivery vector observed was a watering-hole compromise of a regional news outlet, with the exploit JavaScript loaded conditionally based on User-Agent and a TLS JA3 hint suggesting a Chromium stable build in the vulnerable range. The post-exploitation payload was a loader staging a known commodity backdoor variant. Attribution remains partial. The exploitation pattern - selective targeting, narrow delivery window, conditional payload - is consistent with an access broker selling to a state-aligned customer rather than mass criminal use.

In telemetry, the chain is partially visible and partially blind. The renderer RCE itself produces nothing useful. The renderer crashes that ordinarily precede successful exploitation are absent because the exploit is stable. The Mojo message that triggers the escape leaves no trace at the network layer - it is an in-process IPC call, not a syscall or a packet. The browser process compromise becomes observable only at the point execution diverges from normal browser behaviour. On Windows with Sysmon configured to community baseline, Event ID 1 fires when the browser process spawns a non-standard child. Event ID 10 captures the ProcessAccess if the payload reaches into LSASS or another protected process. Event ID 11 logs file writes outside the expected browser profile paths. Event ID 3 logs outbound connections that do not match the browser’s normal destinations. None of these fire on the escape itself. They fire on what the attacker does next.

This is the detection gap. The exploit succeeds in silence. The browser process is trusted by every endpoint product to do unusual things - it makes outbound TLS connections to arbitrary hosts, reads and writes files in the user profile, loads plugins, spawns helper processes. The behavioural baseline for chrome.exe and msedge.exe is wide enough to hide most post-exploitation activity in its lower percentiles. EDR alert categories tuned for malware behaviours often suppress findings inside browser process trees on the assumption that the noise floor is too high. That assumption is the blind spot.

Where detection holds is the second-stage divergence. A browser process loading an unsigned DLL via reflective injection - Sysmon Event ID 7 with a non-Microsoft, non-Google ImageLoaded path - is a high-signal indicator. A browser process opening a handle to lsass.exe with PROCESS_VM_READ - Event ID 10 with GrantedAccess 0x1010 or similar - is decisive. A browser process writing a scheduled task entry, a Run key, or a service registration - Event IDs 12, 13, 14 against HKLM\Software\Microsoft\Windows\CurrentVersion\Run or HKLM\System\CurrentControlSet\Services - is decisive. None of these require knowledge of 40369 specifically. They are post-exploitation invariants. Tuning EDR to alert on browser-process anomalies at this layer closes the gap that the in-renderer and in-IPC layers cannot.

Network-side, the renderer fetch that delivers the exploit is indistinguishable from any other JavaScript download on inspection. TLS-terminated egress is the only viewpoint that sees the payload, and even there the script obfuscation reduces signature value. The harder signal is the post-compromise C2. The observed campaign used domain-fronted HTTPS to a CDN edge with a backend that responded with structured beacon traffic on a ten-minute jitter. JA3/JA4 fingerprinting catches the beacon client if it is anything other than the host browser. If the implant is staged inside the browser process and reuses Chromium’s network stack, the JA3 collapses to the browser’s own and the network distinction is lost. That is the design goal of recent post-exploitation tooling and it works here.

The patch closes the descriptor validation by re-checking the inner length against the residual buffer after header consumption. The fix is small. It is also load-bearing. Pre-patch builds remain exploitable indefinitely against any renderer RCE primitive that lands in the same Mojo-accessible context. Chromium downstream consumers - Electron applications, embedded Chromium frames in third-party products, vendor-forked browsers - inherit the bug on their own update cycles. Electron in particular runs application code with greater trust than a web page and frequently exposes broader Mojo surface to the renderer through nodeIntegration or custom IPC wiring. An Electron app shipping Chromium 128.0.6613.118 or earlier carries the escape primitive into whatever desktop context the application owns. That context is often more privileged than the browser case.

Residual exposure after Chrome Stable updates is not zero. Enterprise deployments running staged rollouts hold vulnerable versions for days to weeks. Managed environments using extended-stable channels carry the bug longer. Embedded Chromium in CI runners, Electron desktop tooling, and kiosk systems updates on its own schedule and often does not. The patch boundary is published. The exploitation primitive is now known to the offensive research community. The exploitation window for the chain remains open against any host where the Chromium-derived process is below 128.0.6613.119 and renderer-reachable JavaScript can be served.

Your valid credentials are the breach.

Sat, 23 May 2026 00:00:00 GMT

5,561 GitHub repositories received malicious commits within a six-hour window. The commits modified GitHub Actions workflow files. They were authored by accounts that already had push rights. The commit messages matched the cadence of routine bot maintenance - dependency bumps, workflow syntax updates, runner image pins. The diffs were small. The signature was missing or matched a previously trusted bot identity. The push velocity across the window averaged roughly fifteen affected repositories per minute. This is supply chain compromise executed at the workflow layer, and the telemetry that should have caught it sits in places most teams do not correlate.

The entry point is the personal access token or the GitHub App installation token. Token theft from a developer endpoint, from a leaked .env, from a misconfigured artefact, from a compromised npm package post-install script reading ~/.config/gh/hosts.yml - the source varies. The outcome converges. The attacker holds a credential with repo scope or workflow scope, or both, across an organisation’s repositories. MITRE T1078.004, valid accounts: cloud accounts. From the GitHub API perspective, every action that follows is authenticated and authorised. No anomaly fires on credential validity. The credential is valid.

The payload is a workflow file modification. The attacker either edits an existing .github/workflows/*.yml or commits a new file under a name that mimics existing patterns - ci-maintenance.yml, dependabot-sync.yml, codeql-config.yml. The workflow registers on a trigger that fires without human review. push to any branch. pull_request_target from forks. schedule on a short cron. workflow_run chained to an existing CI job. pull_request_target is the high-value selector. It runs in the context of the base repository with read/write tokens, not the fork’s restricted token. A PR opened from a malicious fork executes the modified workflow against the protected branch’s secrets.

The job body does three things. It enumerates secrets.* and environment variables. It exfiltrates the contents over an outbound HTTP request to attacker infrastructure - frequently a domain registered within the previous seventy-two hours, frequently fronted by a free TLS certificate, frequently routed through a CDN to obscure the origin. It optionally writes a second-stage payload into the build artefact or container image the workflow produces. The exfil step is where defenders have signal. The GitHub-hosted runner makes the outbound request. The request is logged in the runner’s job log only if the workflow author chose to log it. Most of these payloads pipe to curl with -s and discard stderr. The job log shows nothing useful. The network connection from the ephemeral runner is invisible to the customer’s own EGRESS controls because the runner is not on the customer’s network.

The technique that makes the 5,561 number possible is automation against the GitHub REST and GraphQL APIs. A single compromised token with organisation-wide reach iterates the repository list, clones each repository or uses the contents API to fetch the workflow directory, applies a templated patch, and pushes via the API directly without ever materialising the repository on disk. The rate limit for an authenticated token is 5,000 requests per hour for REST and 5,000 points per hour for GraphQL. The arithmetic for 5,561 repositories across six hours is well within limits if the operation is batched and uses conditional requests. The attacker is not breaking rate limits. The attacker is operating inside them.

The commit camouflage is deliberate. The author email is set to the address of a known bot - dependabot[bot]@users.noreply.github.com, github-actions[bot]@users.noreply.github.com, or a project-specific automation account. GitHub does not enforce that the email in the commit matches the authenticated user pushing it. The commit shows the bot avatar and name in the web UI. Branch protection rules that require signed commits will reject the push unless the attacker has access to a signing key. Most repositories do not require signed commits on the default branch. Most that do require signing exempt bot identities through GitHub App installations, which sign with the App’s GPG key automatically. If the compromised credential is a GitHub App installation token, signed-commit enforcement does not stop the push.

The MITRE mapping is layered. T1195.002, compromise software supply chain, at the strategic level. T1078.004 for the credential abuse. T1098.001, account manipulation: additional cloud credentials, if the attacker mints new tokens or deploy keys for persistence. T1552.004, unsecured credentials: private keys, if the post-exploitation step harvests SSH keys from runner secrets. T1567.002, exfiltration to cloud storage, when the destination is an S3 bucket or equivalent rather than a bespoke endpoint. The MITRE model is useful here only insofar as it forces the question of where each step lives in the customer’s visibility.

The telemetry reality is the part most teams underestimate. GitHub Audit Log captures workflows.created_workflow_run, workflows.completed_workflow_run, repo.add_member, protected_branch.policy_override, git.push events when enterprise audit log streaming is configured. Without streaming to a SIEM, those events live inside GitHub’s interface and expire from the searchable window. The audit log does not capture file-level diffs. It records that a push occurred, by which actor, against which ref. To detect a malicious workflow change, you need either the audit log push event correlated with a repository content scan, or a GitHub Advanced Security workflow that runs on every push to .github/workflows/** and flags modifications. Neither is enabled by default.

EDR on developer endpoints sees the token theft, not the downstream effect. If the initial credential was harvested by a malicious dependency, Sysmon Event ID 1 records the process creation of the post-install script. Event ID 11 records the file read against the credential store. Event ID 3 records the outbound connection. The challenge is that these events occur on a developer workstation hours or days before the GitHub-side actions. Correlating the workstation event to the downstream organisation-wide compromise requires both feeds in the same platform with a join key - typically the developer’s identity or the token hash, neither of which is trivially available.

The runner-side telemetry is the blind spot. GitHub-hosted runners are ephemeral VMs operated by Microsoft. Customers do not get network flow logs, process telemetry, or filesystem visibility into the runner during job execution. Self-hosted runners are the inverse: the customer owns the host and can deploy Sysmon, EDR, or eBPF-based monitoring. Self-hosted runners introduce their own risk class - persistent runners executing untrusted workflows from public forks - but they restore visibility. For organisations on GitHub-hosted runners exclusively, detection has to happen at the GitHub API layer or at the egress edge of the destination, not at the runner.

Detection logic that works against this pattern operates on three signals. First, audit log events for pushes that modify files under .github/workflows/ outside change windows or by accounts that do not normally touch CI. The control is a rule that alerts on any workflow file modification not authored by a member of a defined CI maintainer group. Second, a content-level scan of every push to workflow paths, looking for new outbound network primitives - curl, wget, nc, Invoke-WebRequest, Net.WebClient - in jobs that did not previously contain them. Diff-based scanning is more accurate than full-file pattern matching because most legitimate workflows already contain outbound calls. Third, secret access pattern analysis. A workflow that reads secrets.* for secrets it did not previously read is anomalous. GitHub does not expose which secrets a job referenced in audit log output, but the workflow file itself records the reference and can be parsed at push time.

To check whether you were hit, the operative queries are these. Pull the audit log for the affected window. Filter for git.push events targeting paths under .github/workflows/. Cross-reference the actor against your CI maintainer roster. For every push outside the roster, retrieve the commit and diff the workflow file against the prior version. Look for additions of outbound network calls, additions of secrets.* references that were not previously present, additions of base64-encoded blobs in run: steps, and changes to triggers - particularly the appearance of pull_request_target on workflows that previously used pull_request. Revoke and rotate every secret referenced in any flagged workflow. Revoke and rotate every personal access token and GitHub App installation token in the organisation. Treat token rotation as the boundary of containment, not the patch.

The patch boundary on the attack is the credential lifecycle, not a software version. There is no CVE here. The platform behaved as documented. The compromise lived in the trust granted to a token, the absence of branch protection on workflow paths, and the absence of workflow-file change detection in the audit pipeline. Post-rotation, residual exposure persists in any artefact published during the window - container images, npm packages, language-specific build outputs - and in any downstream consumer that pulled those artefacts before the malicious workflow was reverted. The blast radius of a six-hour window in CI/CD is measured in dependency graph depth, not in elapsed time.

AI is making attackers worse, not better.

Fri, 22 May 2026 00:00:00 GMT

1. Opening Claim

Attacker output is up. Attacker craft is down. The two are not contradictions. They are the same condition observed at different layers of the kill chain. Across phishing samples, initial access tooling, and post-exploitation behaviour collected through 2024 and into 2026, the pattern reported by multiple defender telemetry sources is consistent: more volume, lower variance, weaker fundamentals. The specific operator population producing this pattern is not confirmed. The pattern itself is.

The hypothesis many defenders worked from in 2023 was that generative models would compound attacker capability. Better lures, better code, better evasion. That model was incomplete. It accounted for the upside and not the cost. The cost is now visible in defender data.

Operators who lean on model output stop building the practice that produced quality tradecraft in the first place. The skills that required iteration, failure, and judgement degrade because the model removes the iteration. What is being observed in attacker behaviour is not capability uplift. It is capability substitution, and substitution has a half-life.

2. The Original Assumption

The original assumption rested on three claims. First: AI would close the gap between low-skill operators and senior ones. Second: senior operators would compound their existing skill with model output. Third: the volume of high-quality attacks would rise as a function of both. The defender posture built on that assumption prioritised detection ceiling over detection floor.

That assumption treated attacker skill as additive. Model output plus operator judgement equals stronger attack. It did not account for what happens when operator judgement is no longer exercised. It did not account for the feedback loop between effort and competence. Whether the loop applies uniformly across all operator tiers is not confirmed. That it applies to a significant subset is supported by the convergence in observable tooling.

The assumption also held that model output would remain differentiated across vendors and across operators. It has not. Models trained on overlapping corpora produce overlapping output. Phishing lures generated across multiple providers converge on the same structural patterns, the same phrasing rhythms, the same call-to-action shapes. Defender classifiers benefit from this convergence. Attacker novelty does not survive it.

3. What Changed

Three shifts are observable in current defender data. First, phishing volume is up while phishing variance is down. Lures cluster around a narrower set of templates. Header anomalies, model-shaped sentence construction, and predictable urgency patterns are now reliable signal for classifier-based filtering. The specific reduction in variance is reported by multiple email security vendors. The exact magnitude across the wider population is not confirmed.

Second, initial access tooling derived from model output reuses the same code structures. Loader behaviour, persistence mechanisms, and command staging patterns repeat across unrelated incidents. Threat intel feeds report higher cluster overlap between actors that were previously distinct. Whether this represents shared infrastructure, shared tooling lineage, or shared model dependency is not confirmed. The behavioural convergence at the artifact level is.

Third, operator response under defender pressure has degraded in a specific way. When initial tooling is burned, the observed response is to regenerate from the same model rather than adapt the underlying technique. The adaptation cycle that defined skilled intrusion behaviour requires understanding the control that triggered detection. Model-mediated operators frequently do not exhibit that understanding in follow-on attempts. They produce more output. They do not produce better output. The control that detected the first attempt typically detects the second.

4. Mechanism of Failure or Drift

The mechanism is observable. Capability in offensive operations is produced through iteration against feedback. The operator attempts an action, observes the defender response, adapts the technique, and retries. The product of that loop is judgement about which controls fire, when, and why. Model-mediated workflows compress the loop by removing the operator from the inner steps. The operator describes an outcome. The model produces the artifact. The operator deploys the artifact. When the artifact fails, the operator returns to the prompt rather than the technique.

Each cycle through the model rather than through the control bypasses the step where judgement is formed. Output is generated. Understanding is not. Over repeated cycles the operator accumulates artifacts and loses the structural knowledge those artifacts were meant to encode. This is what is observable in the data. When a loader is burned, the regenerated loader is structurally similar to the burned one. When a lure is filtered, the regenerated lure shifts surface phrasing and retains the underlying construction the classifier was trained against. The defender control that detected the first attempt is exercised again, not evaded.

This is not a claim about model quality. It is a claim about how operational skill is acquired. The model can produce output indistinguishable from senior tradecraft on the first attempt. The cost is paid on the second attempt, when adaptation is required and the operator no longer has the underlying practice to draw on. Whether any individual operator escapes this loop by retaining manual practice alongside model use is not confirmed. The aggregate signal in defender data is that most do not. The drift is not a skill gap. It is a feedback loop break.

5. Expansion into Parallel Pattern

The mechanism is not specific to attackers. It is specific to operators who substitute model output for the practice loop that produced their craft. The same condition is observable wherever that substitution occurs. Defenders using model-generated detection rules without exercising the underlying behaviour the rule encodes are subject to the same drift. The rule fires. The analyst closes the ticket. The analyst does not build the pattern recognition that previously came from constructing the rule manually. When the technique shifts outside the rule’s coverage, the analyst has the same gap the model-mediated attacker has on the opposite side of the engagement.

The mechanism is symmetric because the feedback loop is symmetric. Practice produces judgement. Substitution produces output. Where the substitution is constant, the judgement is not maintained. This applies to triage workflows that route alerts through model summaries before analyst review, to incident response runbooks generated from model output, and to detection engineering pipelines where rule logic is produced from natural-language prompts. The artifacts are functional. The competence required to evaluate them under novel conditions is not produced by their use.

The implication for defender posture is logically necessary from the mechanism, not from outside data. Any control that depends on operator judgement during a live event is exposed to the same drift the attacker side is now exhibiting. If the defender’s response capability is built on the same substitution pattern that is currently degrading attacker capability, the defender’s posture during a non-routine event is not what the tooling inventory suggests it is. Whether this drift is currently present in any specific defender environment is not confirmed. The mechanism applies wherever the substitution is present.

6. Hard Closing Truth

The condition is not that AI made attackers stronger. The condition is that AI changed how attacker capability is produced, and the production pathway is leaking. Volume is up because output is cheap. Variance is down because output is shared. Adaptation is degraded because adaptation requires practice the operators are no longer doing. None of this requires defender heroics to detect. Classifier-based filtering, behavioural clustering, and standard control hygiene are catching it. The detection floor matters more than the detection ceiling in this condition.

The operator position is to refuse the symmetric trap on the defender side. Practice loops that produce judgement must be preserved where judgement is the control. Detection engineers must continue to construct rules manually for the technique classes they own. Analysts must continue to triage a fraction of alerts without model assistance to maintain pattern recognition. Internal red teams must continue to operate manually against the controls they are testing. Tooling is acceptable as a force multiplier on existing skill. It is not acceptable as a substitute for it.

The half-life of capability substitution is not theoretical. It is the mechanism currently producing the convergence visible in attacker telemetry. The same mechanism will produce the same convergence on the defender side if it is allowed to. Identity is the boundary. Practice is the control. Anything that removes the practice removes the control, regardless of which side of the engagement the operator is on. Controls that are not exercised are not controls.

CVSS 5.5 is lying to you

Fri, 22 May 2026 00:00:00 GMT

Opening position

A Linux kernel flaw, present in the codebase for nine years, enables root command execution on major distributions. CVSS is reported at 5.5. The severity score is not the operative signal. Root command execution is the operative signal. Any path that ends in root on a multi-tenant or production host collapses the local privilege boundary, regardless of how the scoring rubric weights the vector.

The age of the defect is the second operative signal. Nine years means the flaw shipped through multiple LTS cycles, multiple distribution rebases, and an unknown number of downstream kernel forks. The exposure surface is not a single release. It is every system that pulled an affected kernel during that window and was not subsequently patched to a fixed version. Specific distributions, kernel versions, and patch identifiers are not confirmed in the provided facts. Treat scope as undefined until the vendor advisories are read directly.

The required action is binary. Patch to the fixed kernel version on every affected host, or accept that any local code execution context on those hosts can be escalated to root. There is no compensating control inside the kernel that neutralises a kernel-level privilege escalation. Mitigations outside the kernel reduce reachability, not exploitability.

What actually failed

A flaw in the Linux kernel permits root command execution. That is the externally observable outcome stated in the facts. The specific subsystem, syscall, code path, and trigger conditions are not confirmed in the input. Do not assume a particular interface was abused. Do not assume the flaw requires unprivileged user context, container escape, or a specific hardware feature. None of those conditions are stated.

The defect persisted in the kernel source for nine years. That duration is a fact. It implies the code path was either rarely exercised under conditions that would expose the flaw, or exercised frequently without producing a signal that triggered review. Which of those is true is not confirmed. Both are consistent with long-lived kernel defects, and selecting one without evidence would be inference.

The CVSS score of 5.5 reflects the scoring model’s weighting of vector, complexity, and required privileges. It does not reflect the operational consequence of the outcome. Root command execution on a Linux host means the attacker can modify any file, load any module, read any memory, and disable any userland security control. The score and the consequence are decoupled. Treat the consequence as authoritative.

Why it failed

The root cause inside the kernel is not described in the provided facts. Stating a specific mechanism, whether use-after-free, race condition, integer handling, permission check bypass, or namespace boundary failure, would be inference. The mechanism is not confirmed. What is confirmed is that the defect survived nine years of kernel review, distribution packaging, and downstream auditing without being identified and corrected.

That survival is the systemic failure. Code review, static analysis, fuzzing, and syscall-level test suites are the controls that exist to catch this class of defect before it ships. For a nine-year-old flaw to reach disclosure, those controls either did not exercise the affected path, did not flag the behaviour when they did, or flagged it without the signal being acted on. Which of those occurred is not confirmed. The control set, as applied to this code path, was ineffective. That conclusion is supported by the outcome.

The distribution layer did not catch it either. Major distributions rebase, backport, and audit kernel changes before shipping to production users. A defect present for nine years passed through every one of those gates on every affected distribution. The distribution review process, as applied to this code path, was also ineffective. Identity is the boundary, and the kernel is the enforcement point for that boundary on a Linux host. When the enforcement point itself contains the bypass, every identity assertion above it inherits the defect.

Mechanism of failure or drift

Phase 1 advisory drift check. The Opening position contains one explicit recommendation: patch to the fixed kernel version on every affected host, or accept that any local code execution context on those hosts can be escalated to root. That is the only operator directive carried forward. No specific kernel version, distribution name, or patch identifier appears in the provided facts. Those remain not confirmed and must be sourced from vendor advisories before any patch action is scoped.

The drift mechanism is the gap between code presence and code scrutiny. The flaw was in the source tree for nine years. The disclosure exists. Therefore the controls that should have detected it either did not run against the affected path, ran without producing a signal sufficient to act on, or produced a signal that was deprioritised. Which of those occurred is not confirmed. The drift is not in the code. The code did what it was written to do. The drift is in the assumption that review, fuzzing, and downstream audit are saturating coverage of the kernel surface. They are not. The surface is larger than the control set applied to it, and a nine-year survival window is the measurement of that gap.

The second drift surface is the trust chain between upstream kernel, distribution maintainer, and operator. Each layer assumes the layer beneath has applied effective controls. The operator trusts the distribution. The distribution trusts upstream review. Upstream review trusts the contributor and the reviewer. When a defect persists for nine years across that chain, every layer’s trust assertion is invalidated for the affected code path. The trust was not verified. It was inherited. Inherited trust is not a control. The mechanism that failed here is the same mechanism that fails in every long-lived defect: presence was treated as proof of correctness because no contradicting signal arrived.

Expansion into parallel pattern

The pattern is enforcement points containing the bypass they are meant to enforce. The Linux kernel is the enforcement point for the local identity boundary on a Linux host. Every userland privilege check, every container isolation guarantee, every capability restriction resolves through kernel code paths. When the enforcement point contains a defect that permits root command execution, the boundary is not weakened. It is absent for any actor who can reach the defective path. The score on the disclosure does not change that. The mechanism is binary: the boundary holds, or it does not.

The same mechanism appears in any system where the entity that enforces a control is also the entity that contains the flaw. A hypervisor with a guest-to-host escape. An identity provider with an authentication bypass. A secrets manager with an unauthenticated read path. In each case, the layer that the architecture treats as the trust root contains a path that invalidates the trust. The defect does not need to be complex. It needs only to exist inside the boundary that everything above it depends on. CVSS scoring tends to weight these by vector and complexity, which is why a root-execution outcome can carry a mid-range score. The score describes the path. The outcome describes the consequence. Operators are accountable for the consequence.

The duration variable amplifies the pattern. A flaw present for nine years has propagated through every system that consumed an affected build during that window. Forks, derivatives, embedded systems, appliances, and offline deployments inherit the defect and do not inherit the patch on the upstream cadence. Which downstream systems are affected is not confirmed in the provided facts. The implication is that the population of vulnerable hosts is larger than the set of hosts running a current general-purpose distribution. Any device running a kernel pulled from an affected source during the nine-year window, and not updated to a fixed version, carries the defect. The patching action must extend to that population, not only to servers under active configuration management.

Hard closing truth

A kernel flaw that permits root command execution is a collapse of the local identity boundary. The CVSS score of 5.5 does not change that. The nine-year survival window does not change that. The absence of confirmed exploitation in the provided facts does not change that. The outcome is defined by what the defect permits, not by what has been observed against it. Operators who wait for observed exploitation before patching are accepting the consequence in exchange for delay. That is a decision. It should be recorded as one.

The required state is explicit. Every host running an affected kernel version must be moved to a fixed version. The fixed version is not confirmed in the provided facts and must be read from vendor advisories. Hosts that cannot be patched on the disclosure cadence must have their local code execution exposure reduced until they can be. That means restricting who can run code on the host, restricting what code can be run, and treating any local execution capability on an unpatched host as equivalent to root. There is no kernel-internal control that neutralises a kernel-level privilege escalation. Userland hardening reduces reachability. It does not reduce exploitability once the path is reached.

Identity is the boundary. The kernel enforces that boundary on a Linux host. When the enforcer contains the bypass, the boundary is not present for the duration that the bypass is present. Nine years is the duration on record for this defect. The patch closes the path on patched hosts. It does not close the path on hosts that are not patched. The work is not the disclosure. The work is the inventory, the patch rollout, and the verification that every affected kernel has been replaced. Anything short of that leaves the boundary open on the hosts that were missed.

See also: NordVPN for tunneled traffic when operating outside controlled networks.

#ad Contains an affiliate link.

GitHub shipped optional hardening as a control

Fri, 22 May 2026 00:00:00 GMT

1. Opening Position

The GitHub breach is being discussed as a surprise. It is not a surprise. The specific technical details of the breach are not confirmed in this briefing. What is confirmed is the public claim that an incident occurred and that the industry is treating it as exceptional. Treating it as exceptional is the error.

The class of failure that produces this kind of event has been documented across more than a decade of public disclosures. Identity systems with permissive defaults. Long-lived credentials. Trust relationships that extend further than the controls validating them. Each instance is reported as a discrete event. The mechanism is the same.

Calling this predictable is not commentary. It is a control statement. If a class of failure has been demonstrated repeatedly across vendors, frameworks, and platforms, and the industry response remains advisory rather than enforcing, then recurrence is the expected condition. The accountability does not sit with the customer who failed to read the hardening guide. It sits with the design model that made hardening optional.

2. What Actually Failed

The specific control failures inside GitHub are not confirmed. What is externally observable is the industry response pattern around incidents of this class. Vendor disclosures arrive after the fact. Indicators of compromise are published as artifacts. Customers are advised to rotate credentials and review logs. None of these are controls. They are notifications issued after the boundary has already been crossed.

The operational model that downstream consumers depend on includes implicit trust in upstream identity systems, token issuance, scope enforcement, package signing, and webhook validation. Where each of these boundaries is enforced by the platform in question is not confirmed without platform-specific documentation. What is confirmed across the industry is that these boundaries are frequently published as guidance rather than enforced by default configuration.

The security industry produces frameworks, maturity models, and certifications. The observable output of these systems is documentation. The observable input to incidents is configuration. The two do not connect through enforcement. They connect through assumed adoption. Assumed adoption is not a control surface. It is a marketing surface.

3. Why It Failed

The design assumption underlying the current model is that customers will configure controls correctly. That assumption is incorrect at scale. Defaults define behaviour for the majority of deployments. If the default is permissive, the deployed state is permissive. Documentation that describes a stricter configuration does not change the deployed state. It changes the audit trail after compromise.

The industry response to repeated incidents of this class has been to publish more frameworks. Frameworks describe what should be true. They do not enforce what is true. A control that is not enforced is not a control. It is a recommendation. Recommendations do not stop attackers. Enforced boundaries stop attackers, and only when the enforcement point sits inside the trust path being abused.

Identity is the boundary. When the identity system permits long-lived tokens, broad scopes, and no continuous validation, the boundary is administrative rather than technical. Administrative boundaries fail under automation. Automation scales both control and failure at the same rate. The systems that issue credentials operate at machine speed. The systems that review credential use operate at human speed. That gap is where the industry has been operating for years, and the gap is not a misconfiguration. It is the design.

4. Mechanism of Failure or Drift

The mechanism is the separation of credential issuance from credential validation. A token is created at one point in time under one set of conditions. It is then accepted at a later point in time under conditions that are not re-evaluated. The system trusts the artifact rather than the state of the principal it represents. Once the artifact exists, the boundary it crosses is administrative. The technical check is whether the token is valid. The technical check is not whether the use is legitimate.

This separation compounds across federated systems. Upstream identity issues a credential. A downstream platform accepts the credential. A further downstream consumer accepts an artifact signed under that credential. Each link validates the previous link. No link validates the principal. The trust path extends, and the enforcement points do not extend with it. Where any single link is compromised, the rest of the chain continues to operate as if nothing has changed. The chain does not have a mechanism for revoking trust in transit. Revocation is published. Acceptance is automatic.

Drift occurs because the issuance side is operated by the platform and the validation side is operated by the consumer. The platform optimises for adoption. Adoption is measured by friction. Friction is reduced by extending token lifetimes, broadening default scopes, and minimising re-authentication. Each reduction in friction is a reduction in enforcement. The consumer is told they can configure stricter behaviour. Configuration is optional. The default is what runs in production. The default is what the attacker encounters.

5. Expansion into Parallel Pattern

The same mechanism is present in package registries. A maintainer credential is issued once. The credential publishes artifacts. Downstream consumers pull those artifacts based on the signature attached to them. The consumer is not validating the maintainer. The consumer is validating the artifact. When the credential is compromised, every artifact published under it is accepted as legitimate until the credential is revoked. Revocation is a notification. The artifacts already pulled are already executing.

The same mechanism is present in cloud identity federation. A role is assumed via a trust relationship configured once. The trust relationship is evaluated at assumption time. The session token issued from that assumption is valid for its lifetime regardless of subsequent changes to the underlying principal. If the principal is compromised after assumption, the session continues. The control surface is the trust policy. The trust policy is configured by the customer. The default trust policies provided by examples and tutorials are permissive. The deployed state matches the examples.

The same mechanism is present in CI/CD pipelines. A pipeline holds credentials that grant access to production. The credentials are scoped by configuration. The configuration is reviewed at commit time. The use of the credentials is not reviewed at execution time. Any code that reaches the execution context of the pipeline inherits the credentials. The boundary between source code review and credential use is administrative. The technical boundary is the execution context itself, and the execution context does not distinguish between intended and unintended use.

6. Hard Closing Truth

The industry has spent a decade producing documentation about this class of failure. The documentation has not changed the rate of occurrence. Documentation is not a control. Frameworks are not controls. Maturity models are not controls. A control is an enforcement point inside the trust path that rejects unauthorised behaviour at machine speed. Anything else is a record of what should have happened.

The accountability for this pattern sits with the platforms that issue the credentials and define the defaults. The customer cannot enforce a boundary that the platform does not expose. The customer can only configure what is offered. When the offering is permissive by default and restrictive by option, the aggregate deployed state is permissive. This is not a customer failure. It is a design decision. The design decision is made by the vendor and absorbed by the consumer.

The GitHub breach is not an outlier. It is the expected output of a system that issues long-lived credentials, accepts them without continuous validation, and publishes guidance instead of enforcing boundaries. The next incident in this class is already in progress somewhere. It will be disclosed later. It will be treated as a surprise. It is not a surprise. Until issuance, validation, and revocation operate inside the same enforcement boundary at machine speed, this pattern continues. The industry knows this. The industry has chosen documentation over enforcement. That choice is the breach.

See also: NordVPN for tunneled traffic when operating outside controlled networks.

#ad Contains an affiliate link.

Malicious commits breached 5,561 repositories

Fri, 22 May 2026 00:00:00 GMT

Opening position

5,561 GitHub repositories received malicious CI/CD commits within a 6-hour window. The commits were styled to match routine bot maintenance activity. Beyond the repository count and the window duration, additional scope details are not confirmed.

The relevant property is not the volume. The relevant property is the disguise. The commits were accepted into repositories at a rate consistent with automation. That rate is only achievable when the receiving systems treat the commit author as trusted by default.

This is not a story about a clever exploit. This is a story about identity boundaries that were never enforced. If a commit looks like a bot, and the pipeline trusts bots, the pipeline executes the commit. The disguise is the payload.

What actually failed

Malicious commits entered 5,561 repositories and were not rejected at the point of ingestion. The commits resembled routine bot maintenance. Whether the commits were authored under a legitimate bot identity, a spoofed identity, or a compromised identity is not confirmed. What is confirmed is that the commits were not stopped.

The receiving repositories did not differentiate between a maintenance commit and a malicious commit carrying the same surface characteristics. Author string, commit message format, and file scope appear to have been sufficient signals for the commits to pass without challenge. Whether branch protection, required reviews, or signed-commit enforcement were present on the affected repositories is not confirmed.

CI/CD systems attached to these repositories would execute on commit by default. Whether any of the 5,561 repositories triggered downstream builds, published artifacts, or propagated the change to dependent systems is not confirmed. The failure observable from the available facts is at the ingestion layer. The commit was accepted. Everything after that point is not confirmed and must be verified per repository.

Why it failed

The commits were accepted because the repositories treated the appearance of a bot identity as equivalent to the authority of that identity. Appearance is a string. Authority is a verified signature tied to a key the repository owner controls. These are not the same thing, and the affected repositories did not enforce the difference.

A commit author field is metadata. It is set by whoever creates the commit. Without signature verification enforced at the branch level, the author field carries no trust value. The 5,561 repositories accepted commits where the trust decision was based on metadata that the attacker controlled. The control that would have stopped this, required signed commits with verified keys at the protected branch level, was either absent, not enforced, or bypassable. Which of these applied per repository is not confirmed.

The second failure is the assumption that bot traffic is low-risk traffic. Bots commit frequently, in small diffs, with predictable messages. Human review fatigue treats this pattern as background noise. Automated review treats this pattern as a known-good shape. Both responses convert a high-frequency identity into an unmonitored ingress path. When the identity is impersonated or compromised, the monitoring gap is the attack surface. The 6-hour window is consistent with an actor moving faster than human review and within the trust envelope already granted to automation.

Mechanism of failure

The mechanism is the substitution of appearance for authority. A repository configured to trust commits from a bot identity is configured to trust a string. The string is set by whoever produces the commit. Anyone who can produce a commit with that string is, from the repository’s enforcement perspective, that bot. The signature is the only object that converts a claim into a credential. The signature was not the gating condition.

This is identity drift, not control failure in the conventional sense. The control was not present to fail. The repositories operated as designed. The design treated a low-friction author label as a sufficient trust anchor. When 5,561 repositories share that design property, any actor who can match the label inherits the trust of every bot they impersonate. The 6-hour window is consistent with scripted commit production. Whether a single actor or coordinated actors produced the commits is not confirmed.

The drift compounds at the automation layer. CI/CD pipelines configured to trigger on commit do not re-verify the author. The pipeline’s trust was inherited from the repository’s trust. If the repository accepted the commit, the pipeline accepts the work. Every layer downstream of the ingestion point operates on the assumption that ingestion enforced something. Ingestion enforced metadata matching. Whether any pipeline executed, what it executed, and what it produced is not confirmed and must be verified per repository.

Expansion into parallel pattern

The same mechanism exists wherever a system uses identity appearance as the enforcement signal. Service accounts identified by name in access policies without bound key verification fail by the same path. The policy grants permission to a label. The label is asserted by the calling process. If a process can assert the label, it inherits the permission. The cryptographic binding between the label and the entity authorised to use it is the only object that converts the policy from a suggestion into a control.

Webhook receivers that validate sender identity by source field or user-agent string carry the identical exposure. The receiver trusts what the sender claims about itself. Any actor that can reach the endpoint and replicate the claim is, to the receiver, the trusted sender. The corrective control in both cases has the same shape as the missing control in the GitHub case: signature verification against a key the receiver controls and the sender cannot forge.

The pattern generalises to any environment where automation runs against high-frequency, low-variance traffic from a labelled source. The label is cheap to produce. The verification is comparatively expensive to enforce. Systems that optimise for throughput drop the verification first. The 5,561 repositories are a count of systems that made that trade in this disclosure. The count of systems across the broader ecosystem that have made the same trade and have not yet been targeted is not confirmed.

Hard closing truth

Identity is the boundary. If the identity is a string the attacker can write, the boundary is decorative. Required signed commits with verified keys, enforced at the protected branch level, is the primitive that converts the boundary from decorative to operational. Any repository that runs CI/CD on commit and does not enforce this is in the same condition the 5,561 were in before the commits arrived.

Audit commit history across every repository under management for the 6-hour window referenced in the disclosure. Compare commit signatures against the keys registered for the asserted bot identities. Any commit from a bot identity without a verified signature against a controlled key is suspect and must be handled as such until proven otherwise. Whether the disclosure has published specific signatures, file paths, or commit message contents associated with the malicious commits is not confirmed. Absence of those indicators does not narrow the audit scope. It widens it.

Bot traffic is not low-risk traffic. It is the traffic least likely to be reviewed and most likely to be trusted. That combination is the attack surface. Treat every automated identity as a privileged identity. Enforce signature verification, scope tokens to the minimum the automation requires, and apply the same review threshold to automation commits that is applied to human commits. A control that is not enforced is not a control. 5,561 is the count of repositories that have now established this. The next count is a function of how many operators act before the next window opens.

Microsoft flags password reset exploitation

Fri, 22 May 2026 00:00:00 GMT

1. Opening Claim

Microsoft has issued a warning that threat actors are exploiting password reset processes to gain access to user accounts. The reset flow is the attack vector. Treat this as a control assessment trigger, not a news item.

The specific techniques used in the exploitation are not confirmed. The scope of affected tenants is not confirmed. The dwell time, persistence mechanisms, and post-access behaviour are not confirmed. What is confirmed is the target: the account recovery path itself. That is sufficient to act on.

The operating position is this. The password reset endpoint is an authentication surface. It issues credentials. It transfers account control. If it can be exploited to gain access, it is functionally equivalent to a login bypass. Every assumption built on top of “the user has authenticated” must now be re-examined against “the attacker triggered a reset.”

2. The Original Assumption

Password reset has historically been treated as a recovery function. The design assumption is that the user has lost access and needs a controlled path back in. Under that assumption, the flow is built for usability first and adversarial resistance second. That assumption is the failure point.

The second assumption is that identity is verified before the reset completes. In practice, the verification step relies on whatever signal the reset flow accepts as proof of ownership. Whether that signal is sufficient is a question of control design. Microsoft’s warning indicates that at least one path through the reset process is producing access for someone who is not the account owner. The exact verification mechanism that failed is not confirmed.

The third assumption is that the reset endpoint is hardened to the same level as primary authentication. This is rarely true. Reset flows commonly accept a broader range of inputs, depend on external channels for verification, and are subject to fewer rate, behavioural, and risk-based controls than the primary login. If those controls are not present on the reset path, the reset path is the lower-cost route. Attackers select the lower-cost route.

3. What Changed

Microsoft has confirmed the reset flow is being actively exploited. That moves the password reset process from theoretical attack surface to confirmed attack vector. The change is not in the technology. The change is in the operator’s required treatment of it.

The specific exploitation technique is not confirmed in the available facts. The attacker access path beyond the reset is not confirmed. Whether the exploitation is targeting consumer accounts, enterprise accounts, or both is not confirmed. Whether multi-factor authentication, conditional access, or risk-based sign-in controls are being bypassed during the reset is not confirmed. These gaps are conditions, not unknowns to be filled with assumed attacker behaviour.

What changes operationally is the classification of the reset flow. It must now be treated as a live authentication path under active exploitation. Logging, alerting, and enforcement on the reset endpoint must match what is applied to the primary login. Identity verification during reset must be continuously validated against signal, not assumed from possession of a recovery channel. If a reset can complete without re-establishing the same trust required for a primary authentication, the reset is the boundary. The boundary is currently being crossed.

4. Mechanism of Failure or Drift

The reset flow fails because it operates on a weaker trust contract than the primary login while issuing the same outcome. Primary authentication binds a session to a verified identity through credentials, multi-factor signal, device posture, and conditional access policy. The reset flow binds a session to whoever can satisfy the recovery challenge. If the recovery challenge is weaker than the primary control, the lower-trust path produces the higher-trust outcome. The control surface is defined by the weakest accepted proof, not the strongest.

The drift is structural. Reset flows accumulate exceptions. A recovery email address added years ago. A phone number ported to a different carrier. A security question seeded with public data. A help desk override path. Each of these is a branch in the verification logic. Each branch was added to solve a usability case. None of them were added with the assumption that the attacker would select that branch deliberately. The attacker selects the weakest branch every time. Whether Microsoft’s affected environments had any of these specific branches in play is not confirmed. The structural condition exists in reset implementations regardless of which branch was exercised.

The second failure mechanism is signal asymmetry. Primary login emits rich telemetry. Device fingerprint, geolocation, behavioural baseline, MFA challenge result, conditional access evaluation. Reset flows commonly emit less. Verification often happens through an out-of-band channel that the authentication system does not own. If the verification signal is not inside the same trust evaluation engine as the primary login, the reset is not being evaluated. It is being processed. Processing is not enforcement. A reset that completes without conditional access, without risk scoring, and without the same logging fidelity as the primary login is a control gap by design. Whether this asymmetry was the specific exploited condition in Microsoft’s warning is not confirmed.

5. Expansion into Parallel Pattern

This is not a password reset problem. This is an account recovery problem. The same mechanism applies to every recovery path in every identity system. MFA reset. Device re-enrolment. Backup code regeneration. Help desk identity verification. Passkey recovery. Each of these is a path that issues authentication state on weaker verification than the primary flow. Each one is a target by the same logic that targets the password reset. The attacker does not need to defeat the primary control. The attacker needs to be the user who lost access.

The pattern is this. Wherever a system offers a way back in for a user who cannot authenticate normally, that path becomes the highest-value target. Every recovery flow built on possession of a channel, knowledge of a fact, or interaction with a human operator can be reframed as a social engineering target or a credential attack against the recovery channel itself. If the recovery channel is an email account, the attack moves to the email provider’s reset flow. The chain is only as strong as the last reset in it. Identity is transitive across recovery dependencies, and the boundary moves with the weakest link.

The same pattern repeats outside the consumer identity surface. Any system with a privileged override exists in this state. Database admin recovery accounts. Cloud root user recovery. Domain registrar recovery. Code signing key recovery. Break-glass procedures. Recovery paths exist because the primary path can fail. They are also where the primary control can be bypassed. Treating them as exceptional flows that sit outside the standard control regime is the defect. They are not exceptional. They are authentication surfaces with different inputs and, in most environments, lower scrutiny.

6. Hard Closing Truth

The reset endpoint is a login. Treat it as one. If it does not enforce the same identity verification, the same signal evaluation, the same conditional access policy, and the same logging fidelity as the primary login, it is the way in. The attacker has already made that determination. Microsoft’s warning confirms the determination is being acted on. The specific technique is not confirmed. The classification of the surface is.

Audit every recovery path in the environment. Enumerate the branches. For each branch, identify what proves identity, where that proof originates, what signal evaluates it, and what control can stop a reset in progress. If any branch cannot answer those four questions with the same rigor as primary authentication, that branch is the exposure. The remediation is to bring the reset flow under the same trust evaluation as the primary flow, or to remove the branch. Branches retained for usability that cannot meet the verification standard are accepted risk. Name them as such or close them.

Controls that are not enforced on the reset path are not controls. Identity is the boundary. The boundary includes every path that issues identity, not only the one labelled sign-in. If a reset can complete without the system continuously validating that the requester is the account owner, the system has already failed. The exploitation Microsoft is reporting is the exercise of that failure. The condition was present before the warning. The warning only changes whether it is treated as theoretical.