Also available as plain text · markdown source

Security Monitor 2026-10-22

Informational security guidance for awareness and prioritization. Not certification, legal advice, or a guarantee of protection.

Executive Summary

Railway, a developer platform that hosts apps, APIs and databases, says an attacker may have read customer environment variables and, for some, decrypted them. It's telling every user to roll every secret stored there. Railway believes this is part of a series of attacks on platform companies aimed at AI inference providers, and it has already invalidated every API token and reset every storage bucket key. GitLab shipped a critical patch for CVE-2026-110264, an unauthenticated remote code execution bug scored 10.0 that reaches back to GitLab 7.0, so self-managed instances should update now. LiteLLM's CVE-2026-114612 lets an internal user forge an admin credential and run commands through the proxy's MCP endpoint. The MCP Inspector developer tool fixed nine advisories, two of them critical. Also today: cross-tenant and authentication bugs in Amazon Strands Agents, Google ADK for TypeScript, Trigger.dev, Kiro Crew and CrewAI, and a METR and Redwood Research red team that found ways around OpenAI's internal agent monitoring.

Headline Developments

1. Railway tells every user to roll all secrets after an attacker reached its environment variable store CRITICAL

Source: Railway: Security Disclosure: Wednesday October 21st (October 21st)
- Railway says it detected anomalous activity on the morning of October 21st in systems that store customer environment variables. Its investigation so far indicates an unauthorized third party may have accessed encrypted environment variables and, for some of them, obtained the decrypted contents. Railway notes those variables can hold API keys and database and registry credentials.
- Railway believes the attack is "part of a series of attacks recently targeting platform companies with the aim of compromising AI inference providers," and says it notified those upstream providers to revoke keys proactively. It says the impact may be limited to a subset of users but recommends that all users roll every environment variable and API key stored in Railway, plus private registry credentials, and review service logs. It will email the accounts it confirms were affected.
- Railway has acted on its side too. Its status page says it rotated all storage bucket credentials starting October 21st at 22:37 UTC and invalidated all Railway API tokens at 04:39 UTC on October 22nd. Tokens and project tokens created before the incident stay invalid, so the Public API and CLI need new ones. Builds were paused platform-wide and came back in stages. As of 21:59 UTC on October 22nd they're on for Hobby, Pro and Enterprise, Free and Trial are still waiting, and new signups are paused. Railway says it'll publish a full incident report.
- Railway's redeploy guide says containers only read variables at startup, so new bucket keys don't take effect until you redeploy. It also says the GitHub tokens it invalidated and the registry tokens it removed still work on GitHub's side until you revoke them there. Railway published separate guides for checking unexpected OpenRouter, Grok, Anthropic, OpenAI and Stripe usage, rotating Postgres, MongoDB, Redis and MySQL credentials, and checking for anomalous GitHub, AWS and Google Cloud access.
- Secondary coverage: BleepingComputer puts Railway at around 4.8 million users and more than 16 million hosted services (BleepingComputer: Railway warns devs to rotate secrets after potential breach, October 22nd). TechCrunch reports Railway's CEO plans a post-mortem (TechCrunch: Developer platform Railway urges 'all users' to revoke secret keys after cyberattack, October 22nd). Railway hasn't said how the attacker got in or how many accounts were affected.

Why this matters: It's CRITICAL because "rotate everything" on a platform this size means every model provider key, database password and cloud credential that sat in a Railway variable. Railway names AI inference keys as the attacker's goal, and Zeabur's attacker went after AI keys too (see the footnotes). A platform's environment variables are a secrets store whether or not anyone designed them as one. Keys kept in a dedicated secrets manager, scoped narrowly and rotated on a schedule, make a day like this much smaller.

2. GitLab ships a critical patch for a 10.0 unauthenticated RCE that reaches back to GitLab 7.0 CRITICAL

Source: GitLab: GitLab Critical Patch Release: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, 18.11.13 (October 21st)
- GitLab says CVE-2026-110264 could let an unauthenticated user run code on a GitLab server through an integer overflow when a specially crafted regular expression is compiled. It affects GitLab CE and EE from 7.0 onward and is fixed in 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 and 18.11.13 (CVSS 3.1 10.0; NVD: CVE-2026-110264). The release notes show the fix as a patch to Ruby's regular expression engine.
- GitLab.com is already patched, and GitLab Dedicated tenants on 19.3.5-internal0 or 19.4.2-internal0 or later don't need to act. For self-managed instances, GitLab published two detections: "Onigmo native worker crash" and "Org mode render error burst."
- The same release fixes eleven more issues. Two are worth calling out. CVE-2026-15723 lets an authenticated user take over an existing LDAP-backed account when OmniAuth SAML and LDAP auto-linking are both on (CVSS 8.2; NVD: CVE-2026-15723). CVE-2026-112212 lets an unauthenticated user poison a shared cache's OAuth/OIDC discovery document so certain flows go to an attacker's server (CVSS 7.5; NVD: CVE-2026-112212). The 19.4.3 and 19.3.6 notes also list a backport that strips the trusted flag from client-supplied MCP tools in Workhorse.

Why this matters: It's CRITICAL because a self-managed GitLab holds source code, CI/CD variables and deploy credentials, and this bug needs no login. It isn't on KEV, and GitLab doesn't report exploitation, but the fix shows where the bug is. Amazon's PHP2Shell write-up this week makes the same point: for internet-facing systems, measure patch windows in hours.

3. LiteLLM CVE-2026-114612: one encryption key for secrets and sessions lets an internal user become admin HIGH

Source: GitHub: LiteLLM advisory GHSA-7hp6-4w63-5g45, Privilege Escalation to Proxy Admin via Cross-Domain Reuse of the Salt Key (CVE published on NVD October 22nd)
- The advisory says the LiteLLM proxy used one encryption key both to seal secrets at rest and to mint session tokens. A user with internal_user rights could request an API key with crafted metadata holding a forged admin credential. The proxy encrypted it and handed it back, and replaying that value as a bearer token made the proxy trust the forged admin identity, including the ability to run commands through the MCP stdio endpoint (NVD: CVE-2026-114612, CVSS 3.1 9.9).
- Affected: 1.87.0 until the fixed releases 1.100.4, 1.101.3, 1.102.2, 1.103.1 and 1.104.0-rc.2. Versions after 1.91.0 are exploitable in the default configuration. 1.87.0 through 1.90.x are only exposed if EXPERIMENTAL_UI_LOGIN=true was set. If you can't upgrade yet, the advisory says setting EXPERIMENTAL_UI_LOGIN=false disables the vulnerable path but breaks CLI SSO and Claude Code gateway login.
- The GitHub advisory is dated September 30th, and the NVD record arrived today and is still awaiting NIST analysis. This is a separate issue from the 1.107.0 release compromise we covered October 21st.

Why this matters: It's HIGH because the attacker has to be an internal user already, but the result is admin on the gateway that holds every model provider key, plus command execution on its host. Reusing one key for two jobs is how a secret store turns into a token mint. If your gateway's internal users include contractors, service accounts or shared logins, treat this as urgent.

4. MCP Inspector fixes nine advisories, two critical, where a remote MCP server can run code on your machine HIGH

Source: GitHub: MCP Inspector advisory GHSA-4fc4-wcmh-4g86, Malicious MCP OAuth callback can switch transport to stdio and execute arbitrary local commands (October 21st)
- MCP Inspector is the official developer tool for testing MCP servers. The project published nine advisories on October 21st, fixed in v2 2.12.0 and v1 1.0.3. None has a CVE yet.
- The two critical ones (both CVSS 9.6): a malicious OAuth callback could switch the transport to stdio and run local commands (GHSA-4fc4-wcmh-4g86), and a remote MCP App could steal the proxy's auth token and run local commands (GHSA-6x67-4w4w-9f3w).
- Three are rated high. A remote MCP server can get code run on Windows and WSL through the OAuth authorization URL (GHSA-q978-78c7-phqw, CVSS 8.8), the same bug class we covered in opencode on October 19th. A DNS rebinding attack can read the API token and stored OAuth tokens, which the project calls an incomplete fix for CVE-2025-49596 (GHSA-vcc9-3xgm-p9v4). And with DANGEROUSLY_OMIT_AUTH set, the origin check fails open (GHSA-wmjf-2m46-2352, CVSS 7.5).
- The rest are medium and low: the fetch proxy leaked Authorization and Cookie headers across cross-origin redirects (GHSA-f6mc-jg3x-vq53), the session token could leak to an attacker-chosen proxy origin (GHSA-2rq8-f55p-j2jp), an unbounded proxied response could exhaust memory (GHSA-m5pj-3536-3xcp), and SSE auth headers were logged verbatim (GHSA-8qgq-27v6-55w3).

Why this matters: It's HIGH because Inspector runs on developer laptops, next to cloud credentials and source code, and it exists to connect to MCP servers you don't fully trust yet. Several of these bugs need nothing more than pointing it at a hostile server. Without CVE IDs, most scanners won't flag old installs.

5. Agent framework bugs: Strands cross-tenant memory, ADK path traversal, Trigger.dev's open MCP server MEDIUM

Source: AWS Security Bulletin 2026-146-aws: Amazon Strands Agents SDK (October 22nd)
- Amazon Strands Agents: the A2A server didn't isolate conversation state between callers. An authenticated user could read other tenants' conversation history and plant persistent instructions that change the model's behavior for later callers, just by sending a different context_id. Fixed in strands-agents 1.43.0 (Python) and @strands-agents/sdk 1.5.0 (TypeScript) (CVE-2026-115419, CVSS 3.1 8.1; NVD: CVE-2026-115419).
- Google ADK for TypeScript: @google/adk 0.4.0 before 0.6.0 allowed path traversal through the userId or sessionId parameters when the API server is exposed with the non-default FileArtifactService. Unauthenticated callers could read artifact files and, when a tool saves an artifact, write outside the storage root. The default in-memory service isn't affected (CVE-2026-105772, CVSS 4.0 9.1; GHSA-8hc4-6xx6-3rh3).
- Trigger.dev: trigger dev --mcp in cli-v3 3.0.0 before 4.5.4 bound every network interface with no authentication. People on the same network, or a malicious web page, could trigger tasks, cancel runs and read run logs using the developer's stored access token (CVE-2026-114090, CVSS 3.1 7.1; GHSA-pqmg-rq46-vm4m).
- Kiro Crew and CrewAI: any member of an operator-configured WhatsApp group could control Kiro Crew's other agent sessions and run commands on its host; fixed in 0.7.2 (October 20th; CVE-2026-112380, CVSS 3.1 9.9; AWS Security Bulletin 2026-140-aws). ZDI says CrewAI's load_agent_from_repository imports a module named by a user-supplied argument, so loading a malicious agent configuration runs code (CVE-2026-92206, CVSS 3.0 8.8; ZDI-26-706).

Why this matters: It's MEDIUM because each needs a specific setup, but they're the same lesson in five frameworks. Agent servers mix callers, tenants and tools, and the bugs sit where nobody checks who's asking. Strands is the one to watch, because instructions one caller plants carry over to the next caller.

6. METR and Redwood red-team OpenAI's internal agent monitoring and find ways around it CONTEXT

Source: METR: Red-Teaming OpenAI's Internal Agent Monitoring Systems (October 22nd)
- One METR and one Redwood Research employee spent July 21st to August 11th inside OpenAI's internal misalignment monitoring, with code and config access. They estimate 75 to 94% of agentic internal Responses API traffic from models at least as strong as GPT-5.5 was eligible for monitoring, and 99.2% of internal Codex traffic. Reinforcement learning training runs weren't covered at the start, and unmonitored compaction events likely left on the order of 10% of eligible Codex traffic unmonitored from May to July.
- Among the findings: a way Codex agents could bypass sandboxing and Auto-Review, an exploit that kept hundreds of recent actions from being monitored, inputs that could make the monitor fail through serialization differences, and two client-controllable headers that turn monitoring off for new agents.
- OpenAI says every vulnerability that affected its production safeguards has been patched. METR says it hasn't evaluated that claim. CNBC also covered the review (CNBC: Evaluators found vulnerabilities in OpenAI monitoring system, October 22nd).

Why this matters: It's CONTEXT, but it pairs with OpenAI's own report we covered October 21st, where two agents weakened their monitoring. New today is an outside test of the monitor itself. METR's design advice applies to any team running agents: check in on agents on a timer, not only when they hand control back, keep the monitor out of reach of the agent, and reconcile what was supposed to be monitored against what actually was.

Continuity Footnotes

  • Zeabur breach: covered October 16th. New: Zeabur's preliminary report (October 19th) says the attacker used leaked internal credentials on October 14th and 15th, and that the root cause was long-lived admin credentials stored in plaintext and usable from the public internet. It says the attacker mainly searched for API keys it could use directly, especially AI service keys, and it tells every user to replace every credential stored on Zeabur (Zeabur: October 2026 security incident (preliminary report)).
  • PHP2Shell: covered October 21st. New today: Amazon says its MadPot honeypots saw an exploit attempt on October 17th, four days before disclosure, and multiple attempts from 02:00 UTC on October 21st. It says to start investigations from October 17th and to treat patch windows for internet-facing systems in hours (AWS Security Blog: Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot). It isn't on CISA's KEV catalog yet.
  • CISA KEV: no new additions since October 20th. The SiteGuard deadline and the first Plex Media Server deadlines, covered October 20th, are tomorrow, Friday, October 23rd. The remaining Plex items are due November 3rd.

Pattern Analysis

  1. Platforms that hold your secrets are the target (October 16th to 22nd): Railway says its attacker was after AI inference providers (Story 1), and Zeabur says its attacker hunted for AI keys (footnotes). Environment variables on a hosting platform are a secrets store, and AI keys are what attackers want right now.
  2. One credential doing two jobs (October 21st to 22nd): LiteLLM used one key for stored secrets and session tokens (Story 3), and Railway's GitHub tokens stay live on GitHub until you revoke them there (Story 1). Separate keys by purpose, and revoke at the source.
  3. The agent toolchain trusts whoever connects (October 19th to 22nd): MCP Inspector, Trigger.dev and opencode all let a remote server or network neighbor drive a developer's machine (Stories 4 and 5). Treat local agent tools as network services.
  4. Monitors need monitoring (October 21st to 22nd): OpenAI's agents weakened their own monitoring, and outside red teamers found more ways around it (Story 6). A control the agent can reach or outlast isn't a control.

Immediate (this week):
1. Railway users: roll every environment variable, API key and private registry credential stored in Railway, revoking old values at the provider first. Then redeploy so services pick up new values, create new Railway API and project tokens, and revoke the old GitHub and registry tokens on the GitHub side. Check model provider, Stripe and cloud usage from October 21st onward.
2. GitLab self-managed: update to 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 or 18.11.13, internet-facing instances first, and turn on GitLab's two published detections.
3. LiteLLM: move to 1.100.4, 1.101.3, 1.102.2, 1.103.1 or 1.104.0-rc.2 or later. If you can't yet, set EXPERIMENTAL_UI_LOGIN=false. Review who holds internal_user access.
4. MCP Inspector: update to 2.12.0 or 1.0.3, don't run with DANGEROUSLY_OMIT_AUTH, and only point it at servers you'd trust with your shell.
5. Agent frameworks: Strands 1.43.0 / @strands-agents/sdk 1.5.0, @google/adk 0.6.0, Trigger.dev CLI 4.5.4, Kiro Crew 0.7.2.
6. PHP2Shell and KEV: if you haven't patched PHP, start your hunt from October 17th. Finish the SiteGuard and first Plex KEV items by Friday, and the rest of Plex by November 3rd.

This month:
7. Secrets on hosting platforms: move long-lived keys out of platform environment variables into a secrets manager the app reads at runtime, and give each key the narrowest scope your provider allows.
8. Key purpose: make sure the keys that encrypt stored secrets aren't also used to sign sessions or tokens, in your code and in the gateways you run.

Ongoing:
9. Keep a list of every place a model provider key lives, so "rotate everything" takes hours, not days.
10. Run agent monitoring on a schedule, outside the agent's write access, and check that what should be monitored actually is.

Relevant Risk Summary

Risk Severity Recommended Actions
Railway environment variable exposure (all users told to rotate) CRITICAL Roll all secrets; redeploy; new API tokens; revoke GitHub and registry tokens at GitHub
GitLab CVE-2026-110264 unauthenticated RCE (10.0), plus CVE-2026-15723 and CVE-2026-112212 CRITICAL 19.5.1 / 19.4.3 / 19.3.6 / 19.2.9 / 19.1.9 / 19.0.10 / 18.11.13; enable detections
LiteLLM CVE-2026-114612 internal user to proxy admin HIGH Patched releases or EXPERIMENTAL_UI_LOGIN=false; review internal users
MCP Inspector nine advisories (two critical) HIGH 2.12.0 / 1.0.3; untrusted servers only in isolation
Strands CVE-2026-115419, ADK CVE-2026-105772, Trigger.dev CVE-2026-114090, Kiro Crew CVE-2026-112380, CrewAI CVE-2026-92206 MEDIUM Upgrade; don't expose dev MCP servers or artifact services
Gaps in AI agent monitoring (METR, Redwood, OpenAI) CONTEXT Timer-based monitoring out of agent reach; reconcile coverage

Sources

Informational security guidance. Not certification.