Mirror SecurityReflections
Menu
Book a Demo
Model release · alpha22 October 2026Model release

Mirror Cyber.
Built for defenders.

Introducing Mirror Cyber, our security reasoning model in ETF. Built to support defenders from investigation to remediation, it works with MJEV, a security harness, and independent verifiers to turn evidence into actions teams can inspect, test, and improve.

Explore the workflowsSee how it works together

Why we brought
the alpha forward.

This week brought security work across several layers of the stack. PHP released fixes for two critical remote code execution vulnerabilities on October 21. Node.js published runtime security updates the same day. Google’s October 20 account of compromised eMudhra intermediate CA keys raised a different question: which clients still trusted those keys? PHP advisory · Node.js advisory · Google’s incident account.

The pressure extends to web infrastructure and security appliances. Recent NGINX fixes cover memory-safety issues whose exposure depends on enabled features and configuration. Cisco’s October 14 Secure Email Gateway advisory describes a critical flaw with active exploitation. These layers matter because a shared component or gateway can sit in the path of many services. NGINX advisories · Cisco advisory.

For defenders, each disclosure starts a chain of work: identify affected systems, assess exposure, investigate possible exploitation, apply the right change, and establish that it worked. The details differ between a runtime flaw and a trust failure, but both demand coordination across security, engineering, and operations.

These developments brought forward our release of Mirror Cyber. We have been working on how a security reasoning model can participate in that whole response, with the context, tools, and verification needed to make its output useful. The workflows in this post share some of that work and what we learned from running it.

From evidence
to verified action.

A useful response needs several capabilities working together. Someone must interpret the evidence, choose a next step, carry out the permitted action, and test its effect. Mirror Cyber, MJEV, the harness, and independent verifiers each contribute to that process.

Mirror Cyber: security reasoning.

Mirror Cyber is the model for analyzing code, logs, and other supplied evidence. Teams can use its output to develop an explanation, investigate an attack path, propose a patch, or design a defensive check. The workflow retains the supplied evidence alongside the model’s analysis.

MJEV: focused decisions.

MJEV is Mirror’s existing decision model. It evaluates a specific question against a defined set of outcomes—for example, whether measured results support proceeding or require review. Its role is to support decisions between steps. Independent checks still determine whether the required behavior has been demonstrated.

The harness: context and execution.

The meta-harness coordinates the workflow: evidence collection, model calls, state, tool access, permissions, and execution. Its integrations can connect repositories, scanners, telemetry, asset inventories, sandboxes, tickets, and deployment systems through APIs, SDKs, command-line tools, or MCP servers, according to the workflow’s requirements.

Verifiers: evidence of the outcome.

Tests, runtime probes, artifact comparisons, detection checks, and service-health measurements establish what changed. The harness records those results and routes failed or incomplete checks back for investigation. Analysts and service owners assess conclusions and authorize actions according to their operating policies.

HOW THE PARTS WORK TOGETHER

One response, with evidence at every step.

Evidence & operating contextAdvisories · code · assets · telemetry · response policies
Security harnessContext · state · permissions · orchestration · evidence record
01 / REASONMirror Cyber

Analyze evidence.
Propose the response.

02 / ACTTools & systems

Run the permitted investigation or change.

03 / VERIFYIndependent checks

Measure behavior, artifacts, and health.

04 / ASSESSMJEV

Assess the result for the next decision.

Tool connections: APIs · SDKs · command-line tools · MCP

Failed checks or missing evidence return to investigation and review.
A response supported by evidenceVerified change · recovery record · tested detection · analyst handoff
A representative response path. The harness can revisit steps or request review as evidence changes. Operators set the objective and approval policy; model assessments cannot override failed checks.

Our own runs made the importance of those connections clear. MJEV initially returned review when the evidence was ambiguous. Clear measurements and a question tied to the workflow made its assessment useful. A proposed action from Mirror Cyber then had to pass the harness’s validation, execute through a scoped tool, and produce a result that could be checked independently. That experience shaped how we connect the components.

Keep sensitive evidence
protected along the way.

Connecting these capabilities brings internal code, infrastructure details, traces, and incident evidence into the workflow. Protecting that material is part of the design. In our integration, the client encrypts model input before sending it and decrypts the response on return. Both models use protected request and response paths.

The harness is the client endpoint and makes the decoded results available to its operator. Tool access, saved evidence, traces, and downstream systems have their own access and retention boundaries. The model round trip is one part of that larger protection policy.

Put the same capabilities
to work across security.

An investigation can lead to a patch, a recovery action, a new detection, or another evidence request. The harness can be adapted around that objective and the tools a team uses. Here are several paths we have worked through.

Incident response: connect a finding to a response.

Investigators can use the Mirror Cyber model to compare explanations from process, network, identity, and application evidence. The harness brings in authorized sources and carries a proposed containment action through the required checks and approvals. MJEV can help route the result to the next step or analyst review.

In our incident workflow, an archived compromised package becomes an intake record, then a quarantined artifact whose bytes are verified against the original. This exercises evidence handling and a scoped containment action. Inspect the incident workflow →

Vulnerability management: carry a finding through remediation.

Connect an advisory to the affected runtime, reachable code, service owner, and business impact. With that context, Mirror Cyber can propose a patch or upgrade plan. The harness coordinates the permitted change and verification; deployment integrations can extend the record to the instances that received it.

We worked through a vendor runtime update, with probes that fail before the change and pass afterward. In a deployed service, completion also means replacing affected instances, verifying the active runtime, and checking service health with a rollback path available. Inspect the remediation workflow →

SRE: restore service and verify recovery.

When errors rise after a change, the harness can supply configuration, traces, and recent diffs to Mirror Cyber for diagnosis and a proposed recovery plan. Health checks establish the result, while MJEV can assess whether to continue observation or request review. The workflow retains the service’s rollback permissions and stop conditions.

Our recovery run records failed HTTP requests, restores a disabled dependency configuration, and measures successful responses afterward. Inspect the recovery workflow →

Payload analysis: turn attack evidence into defensive work.

Analysts can use Mirror Cyber to examine captured code, explain suspected behavior, and develop indicators or regression tests. The harness preserves provenance and controls access to analysis tools. Extracted findings can then feed incident triage, remediation, or detection work.

We analyzed an archived malicious payload and checked the model’s cited excerpts against its original bytes. Those checks establish source accuracy; analysts still assess the behavioral interpretation. Inspect the analysis workflow →

Detection engineering: test the proposed defense.

Findings become useful detections when their behavior is tested against relevant examples and controls. In our run, Mirror Cyber proposes a literal-matching rule, a tool executes it against the compromised package and comparison samples, and MJEV assesses the measured results. The record contains the rule, checks, and coverage of that sample set. Inspect the detection workflow →

Connect the advisory
to a check that matters.

Each advisory needs a check tied to its failure mechanism. For Node and eMudhra, we can show the measured behavior before and after the vendor update.

21 OCT 2026 · PHP

Verify the runtime serving web requests.

PHP’s advisory identifies CVE-2026-109618 and CVE-2026-109619, involving out-of-memory handling and stale request state. Fixed releases are 8.5.12, 8.4.27, 8.3.36, and 8.2.35. The response needs to identify the runtime actually serving requests, apply the appropriate vendor update, and confirm the active workers use it. PHP is release context and investigation guidance here; the recorded runtime checks below cover Node.

PHP’s security advisory

21 OCT 2026 · NODE.JS

Test the behavior the update is meant to change.

Among Node’s October 21 fixes, CVE-2026-105482 addresses DNS resolution truncating names containing a NUL character. Patched releases are 22.23.4, 24.22.1, and 26.12.1. Our workflow compares 22.23.3 with 22.23.4 against a controlled DNS server and checks that invalid input is rejected. It covers this behavior rather than every issue in the release.

Node.js security advisory · 22.23.4 release and checksums

20 OCT 2026 · TRUST INFRASTRUCTURE

Check the real affected certificate chains.

Google reported compromised eMudhra intermediate CA keys, prompting trust updates across clients. We tested the researcher’s 12 public TLS endpoints using the actual affected chains, with normal certificate and hostname verification enabled.

Node 22.23.3 accepted six endpoints; Node 22.23.4 rejected all twelve with CERT_REVOKED. The other six already failed on the old runtime because it could not build their issuer chains. The accepted chains matched the published affected-key fingerprints. An unaffected endpoint remained trusted by both runtimes.

These are fresh connections from the tested binaries. Operational follow-through includes checking other clients, custom trust stores, and existing sessions; Node’s change notes that resumed sessions are not re-verified.

Download the real-chain verification record · Researcher’s public checker · Google’s incident account · Node’s trust update

RECENT ADVISORIES · WEB INFRASTRUCTURE & SECURITY GATEWAYS

Prioritize the deployment, including its configuration.

For NGINX, CVE-2026-15176, CVE-2026-93479, and CVE-2026-97205 involve alias/rewrite handling, script evaluation, and asynchronous file I/O. The upstream list identifies 1.31.7+ and 1.30.6+ as fixed. Its severity labels differ from the critical CVSS ratings in Singapore CSA’s October 21 alert; applicability still requires checking the deployed product and configuration. Upstream version guidance · CSA alert.

Cisco’s CVE-2026-76519 affects Secure Email Gateway under specified file-reputation and scanner-version conditions. Cisco rates it critical, confirms active exploitation, and supplies checks for compromise. It illustrates why a response can require investigation and recovery alongside an update. Cisco’s affected-product and response guidance.

PHP, NGINX, and Cisco provide response context here; the recorded runtime remediation covers Node.

The workflow records below show how the model and harness connect a proposed action to its verification. The real-chain check above is an additional verifier run; it contains no model calls.

Qualify the response.
Keep approved requests working.

A vulnerability becomes an incident through the behavior around it. Our qualification case uses a service-discovery client that approves a requested name by suffix, asks DNS for its service endpoint, and makes an HTTP request to that endpoint. Its original policy is deliberately weak. Both destinations and the DNS server run on loopback; the internal service returns a harmless marker.

The observed path on Node 22.23.3
  1. Malformed discovery nameA NUL-containing name passes the raw suffix check.
  2. Different DNS lookupThe vulnerable resolver queries the name before the NUL.
  3. Internal service reachedThe client follows the discovered endpoint and retrieves the marker.

The measured goal is an unintended internal request. This combines CVE-2026-105482 with two application weaknesses: approving an unparsed name and trusting the discovered destination. The runtime behavior is real; the application and internal marker are a constructed scenario. A normal request for the internal name is rejected, while the malformed name reaches it on the old runtime. Node advisory.

The harness gives that trace to the Mirror Cyber model to explain the path and propose remediation. Its permitted action updates the isolated runtime, validates discovery names, and pins the allowed destination. Independent probes then test each control separately and together; MJEV assesses the resulting checks before the workflow can complete.

Measured qualification results. The original setup establishes the failure; each mitigation prevents the internal request.
ConfigurationQualification resultInternal requestsApproved request
Original runtime and weak application policyInternal marker retrieved1Succeeded
Vendor runtime update aloneBlocked by patched resolver0Succeeded
Strict name validation on the old runtimeBlocked by input validation0Succeeded
Pinned destination on the old runtimeBlocked by destination policy0Succeeded
Applied runtime and application controlsBlocked by input validation0Succeeded

Download the measured qualification record. These measurements come from the independent verifier. A model-assisted run separately records Mirror Cyber’s plan and MJEV’s assessment.

This qualification covers the discovery-to-HTTP path. The eMudhra results above test TLS trust separately.

Run the qualification workflow →

Explore the workflows
and their evidence.

Run a fresh workflow or inspect a completed execution. Each run connects Mirror Cyber and MJEV to bounded tools and independent checks in an isolated service environment.

ALPHA · LIVE WORKFLOWS · ISOLATED ACTIONS · MEASURED RESULTS

Checking live workflow availability…

Choose a workflow. Saved runs are actual recorded executions, not generated previews.

Static attack samples are never installed or executed. SRE faults are deliberately injected into a real local service. A verified run means its declared checks passed, not that a production incident is resolved or a detector has general coverage.

Investigate exposure
and signs of compromise.

Remediation establishes the current state; investigators must also examine the exposure window before the fix. Identify the affected version and reachable code path, then correlate possible exploitation with its consequences. NCSC recommends investigating for compromise alongside remediation when exploitation is occurring. NCSC response guidance.

Preserve original logs and artifacts, record collection times and handlers, and hash exported evidence. Capture volatile evidence where feasible without delaying urgent containment. Record missing sources and retention gaps. These gaps limit any conclusion that no compromise was found. Australian Signals Directorate evidence guidance.

Use the following investigation leads alongside vendor-provided indicators and the organization’s own evidence.

PHP request handling: correlate requests with worker activity.

Establish which web-facing workers ran an affected build and when they were updated. Correlate available request and error logs with memory exhaustion, worker crashes, unexpected child processes, file changes, and outbound connections. Errors alone do not prove exploitation, and a successful attack may leave no crash. PHP notes that the demonstrated attack can occur before application code runs, so application logs alone may miss relevant activity. These are investigation leads, not a confirmed exploit signature. PHP’s advisory.

For PHP, Cloudflare reports observed attack traffic and attempts to evade its WAF protections, and still recommends patching. An alert match can establish an attempt; the request, response, and host evidence determine what can be said about its outcome. Cloudflare’s observations.

Node DNS handling: follow the input to the destination.

Check whether untrusted hostnames reached the affected resolver. Where captured, compare original input, validation decisions, DNS queries, and outbound connections for NUL-related truncation or unexpected destinations. Raw input may differ from an escaped log representation. Correlate suspicious requests with access to internal services, unusual authentication, or data access. A matching input alone does not prove a successful breach; the actual consequence depends on the application. Node’s advisory.

Compromised CA keys: establish what the client trusted.

Identify the client’s trust store and update state during the exposure window. Where retained, examine observed certificate chains and public-key fingerprints against the vendor’s affected keys, then correlate connections with unexpected endpoints, DNS or proxy changes, and subsequent account activity. Certificate Transparency can help investigate issuance, but its coverage and enforcement depend on the client. A compromised signing key makes impersonation possible; it does not by itself show that a particular session was intercepted. Google’s account of the trust incident.

Security gateways: follow the vendor’s forensic guidance.

For the Cisco issue, inspect the documented system-log indicators on each cluster member and correlate with external network and firewall records. Cisco warns that privileged attackers can hide evidence on the device. Preserve forensic information before recovery steps; a compromised appliance may require rebuilding and credential renewal under the vendor’s procedure. Cisco investigation and recovery guidance.

Malicious dependencies: trace the artifact into use.

Compare lockfiles, build records, package hashes, and deployed bundles with the affected artifact. Establish whether its code was loaded and which environments or users received it. Examine relevant endpoint and browser telemetry, unexpected network activity, and application or transaction changes consistent with the payload. The archived package in our workflow is source evidence; finding its bytes does not establish execution or downstream harm.

How Mirror supports the investigation: investigators can use the Mirror Cyber model to organize supplied evidence into a timeline, compare explanations, and identify the next query or defensive check. The harness can run authorized searches and preserve the records behind each conclusion, including gaps that need further collection or analyst review.

A useful investigation record states the affected assets and time window, observed activity, supporting evidence, unresolved questions, actions taken, and checks still required. Close with a conclusion that matches the evidence: confirmed compromise, suspected compromise, or no evidence found within the stated coverage.

Make the response
repeatable.

The same evidence gaps and operational lessons should shape preparation for the next disclosure. We suggest NIST CSF 2.0 as the organizing framework, with NIST SP 800-61 Rev. 3 for incident response. Together they connect preparation, detection, response, and recovery to ongoing risk management. The following is our practical application to these workflows. NIST CSF 2.0 · Incident response guidance.

Govern: establish responsibility.
Name service owners, escalation contacts, remediation deadlines, and who can authorize containment or rollback.
Identify: know what is running.
Maintain runtime, dependency, image, and trust-store inventories. Record exposure, business impact, and the owner of each affected service.
Protect: make change repeatable.
Keep supported versions, least-privilege access, tested update paths, rollback plans, and recoverable backups.
Detect: retain useful evidence.
Collect application, DNS, network, identity, and endpoint telemetry with synchronized timestamps. Test retention and retrieval before an incident.
Respond: investigate while reducing exposure.
Preserve evidence, scope affected assets, apply authorized containment, and track each remediation to an owner.
Recover: verify and learn.
Check deployed versions, trust settings, and service health. Monitor for recurrence and turn findings into regression tests and revised response procedures.

Prioritize using the vendor advisory, evidence of exploitation, reachability, and business impact. CISA’s Known Exploited Vulnerabilities catalog is one useful input; absence from it does not establish safety. CISA’s risk-based prioritization guidance.

These practices give the harness a durable operating context: known assets, named owners, accessible evidence, and tested response procedures. Each completed investigation can improve that context for the next one.

Evidence and methods.

Archived artifacts
The incident, payload-analysis, and detection workflows use Datadog’s archived compromised debug@4.4.2 package and an earlier npm release as a control. Source URLs and hashes identify the artifacts; the sample is read as data. Dataset and methodology.
Runtime and recovery checks
The model-driven remediation workflow compares real Node resolver behavior and retains a repeatable synthetic TLS regression check. The separate eMudhra record tests the researcher’s real affected certificate chains over public TLS connections. The SRE run measures recovery from an injected configuration fault in a running service. The chained workflow uses real DNS resolution and HTTP requests in a constructed service-discovery application, comparing the original path with independent and combined controls.
Execution records
The model workflows invoke fixed tools through a local MCP server and record their results and timings. The real-chain verifier uses ordinary TLS clients without test hooks. Runtime hashes, certificate fingerprints, and collection times are included in its downloadable record. MCP tool protocol.
Reading the results
Each run establishes its stated outcome for the tested inputs. Citation checks establish source matching; detection checks cover the declared sample set. The records are not measurements of general model accuracy, release speedup, or production-wide remediation.

A shorter path
from finding to response.

The work we have shared is a starting point for bringing security reasoning into the response process. We are continuing to develop the integrations and verification needed for broader use. Mirror Cyber remains in alpha, and capacity planning is underway as we prepare to expand access.

Explore the workflow evidence