The Security Brief: DECODED — Issue #006
Issue #006
Tuesday, June 17, 2026
The Security Brief: DECODED
By Danielle Peters  ·  Decode Media
Welcome to Issue #006. This newsletter exists because cybersecurity is national security — and most people covering it are either oversimplifying it or missing the point entirely. Every Tuesday, you get real threats, real cases, and real analysis. No hype. No shortcuts. Let's get into it.
🛡
A fake bug report hijacked AI coding agents and ran the attacker's code. No malware. No stolen password. No breach required.

Last week Meta's AI chatbot handed attackers 20,000 Instagram accounts because it was trained to be helpful and not trained to be skeptical. This week, a research team at Tenet Security disclosed something that takes that same problem and drops it into every developer's machine.

They call it Agentjacking. Published June 12, it is already being called one of the most structurally significant AI attack disclosures of the year — not because of what it exploited, but because of what it could not be stopped by.

Sentry is an open-source error-tracking and performance monitoring platform used by tens of thousands of development teams. When something breaks in a software application, Sentry logs an error event so developers can investigate and fix it. Most developers have Sentry integrated with their AI coding agent — tools like Claude Code, Cursor, or Codex — so the agent can automatically pull error reports and suggest or apply fixes.

The attack starts with a Sentry Data Source Name (DSN) — a credential that identifies where Sentry should send error reports. DSNs are intentionally public — embedded in frontend JavaScript so errors can be reported back automatically. Anyone can find one. Any attacker can use one.

Here is what Tenet's researchers did: they sent a crafted error event to Sentry using a target organization's public DSN. Inside that fake error report, they embedded a hidden "Resolution" section — instructions formatted to look exactly like legitimate Sentry remediation guidance. When a developer asked their AI coding agent to resolve open Sentry issues, the agent queried Sentry, received the injected event, and executed the attacker's instructions. With the developer's own credentials. On the developer's own machine.

The attack worked at an 85% success rate across Claude Code, Cursor, and Codex. Tenet confirmed successful execution against targets ranging from individual developers to a Fortune 500 enterprise — 2,388 organizations simultaneously exposed. Victims saw only normal diagnostic output. No alert fired. Nothing looked wrong.

Here is the part that matters for every security team: endpoint detection and response (EDR) tools, web application firewalls, identity and access management policies, VPNs, Cloudflare, and standard firewalls all passed the attack without triggering. Tenet named this the Authorized Intent Chain. The developer authorized the AI agent. The agent authorized the MCP (Model Context Protocol) connection to Sentry. Sentry is a trusted service the developer explicitly integrated. Every step in the chain is authorized. No anomaly exists to detect.

Sentry was notified June 3. They acknowledged the issue and declined to implement a structural fix, calling it "technically not defensible" at the platform level. Their mitigation: a content filter targeting one specific payload string from the proof of concept. The attack class itself remains open.

The structural problem: The Meta HTS exploit was social engineering against an AI. Agentjacking is prompt injection against an AI agent through a trusted data channel. Both work for the same reason — current AI models cannot reliably distinguish between data they are reading and instructions they are being told to follow, especially when those instructions appear inside output from a service the agent was explicitly authorized to use. This is not a Sentry problem or a Claude Code problem. It is an architectural characteristic of how AI agents process MCP tool output, and it applies to every integration that returns externally influenced data to an agent.

If your development teams are using AI coding agents with any third-party integrations — and most are — this is your threat model right now.

🔍
Splunk — the tool your SOC uses to detect attacks — just got a no-auth RCE flaw. An attacker who owns your SIEM can blind your defenders.

Splunk Enterprise is a SIEM — Security Information and Event Management platform — the software security operations centers use to collect logs, detect threats, and investigate incidents. Organizations feed their entire security event stream into Splunk. It sees everything.

CVE-2026-20253, disclosed June 10 with a CVSS score of 9.8, allows an unauthenticated attacker — no username, no password, no credentials of any kind — to achieve full remote code execution on a vulnerable Splunk Enterprise server. The flaw lives in a PostgreSQL sidecar service introduced in Splunk Enterprise version 10. That service exposes endpoints with zero authentication controls. Any attacker who can reach the Splunk web interface can hit those endpoints and execute code.

The attack chain: the attacker writes a malicious payload to the Splunk file system using a standard PostgreSQL database function called lo_export. When Splunk processes that file, the payload executes as the Splunk service user — which in most enterprise deployments carries significant system-level privileges. The attacker now has access to every log, every alert, every credential and configuration detail stored in the SIEM. On AWS-hosted deployments, the sidecar is active by default — cloud instances are exposed out of the box.

A compromised SIEM is not a breach. It is a blind spot. An attacker controlling Splunk can suppress alerts, delete log evidence of their own activity, and monitor the security team's investigation in real time. The tool built to detect attacks becomes the attack surface.

Affected: Splunk Enterprise versions 10.x below 10.0.7 and 10.2.4. Splunk Cloud is not affected. If you are running on-premises Splunk Enterprise — patch now. As an interim control, restrict network access to the Splunk management interface.

📁
ServiceNow knew about a zero-auth API flaw in April. They patched it June 5. They didn't tell anyone until June 9 — and only if you had a portal login to find it.

ServiceNow is the enterprise IT service management platform most large organizations use to manage IT support tickets, employee records, asset inventories, security incident tracking, and internal workflows. When ServiceNow gets breached, the contents are not just sensitive — they are the map of how your organization operates.

The flaw: a Scripted REST API endpoint had its authentication parameter set to requires_authentication=false. One misconfiguration meant anyone on the internet could query data from customer instances with no credentials. Confirmed unauthorized queries hit customer data June 2–3, all traced to a single external IP.

The timeline:

→ April 22 — A researcher submitted a confidential bug bounty report describing the exact flaw

→ June 2–3 — Active unauthorized queries hit customer instances

→ June 5 — ServiceNow silently patches hosted instances

→ June 9 — ServiceNow posts a bulletin — hidden behind a customer support portal login

→ June 10 — Bulletin posted to Reddit, public reporting begins

ServiceNow has since attributed the activity to security researchers in responsible disclosure, not malicious actors. But the accountability question is not who was querying — it is why organizations subject to GDPR's 72-hour notification requirement, SEC cybersecurity disclosure rules, or HIPAA obligations could not start their compliance clocks until someone posted a login-gated notice to Reddit.

ServiceNow received the vulnerability report on April 22. The patch came 44 days later. Data potentially exposed: IT support tickets, employee records, internal documentation, asset inventories, security incident reports, and system configuration details.

If you are running ServiceNow: review transaction and node logs for June 2–5, look for Guest user account activity and API calls from IP 51.159.98.241, and audit authentication settings on every Scripted REST API endpoint.

🌐
Iran-affiliated hackers are actively disrupting U.S. water utility PLCs. The attack vector is an internet-exposed industrial computer with a default password.

In April 2026, the FBI, CISA, and partner agencies confirmed that an Iranian-affiliated APT — Advanced Persistent Threat, meaning a state-backed hacking team — has been disrupting PLCs (programmable logic controllers) across U.S. critical infrastructure sectors since at least March 2026. Water and wastewater systems are the primary target.

A PLC is a small industrial computer that controls physical processes. In a water treatment facility, it regulates chemical dosing, pump pressures, and flow rates — the systems that determine whether your drinking water is safe. When an attacker disrupts a PLC, the consequence is not a data breach. It is a physical outcome.

The attack vector is exactly what you would expect from a sector that has historically underfunded cybersecurity: PLCs left directly internet-exposed, frequently with default or no passwords. CISA has flagged the water sector's structural vulnerabilities for years — zero dedicated cybersecurity personnel at most utilities, aging SCADA (Supervisory Control and Data Acquisition) systems running end-of-life operating systems, flat network architecture with no separation between the corporate email server and the chemical dosing controller.

This campaign is an escalation of the 2023 CyberAv3ngers operation, where IRGC Cyber Electronic Command-affiliated operators accessed Unitronics PLC devices at U.S. water facilities using default passwords. This round is broader and more operationally mature — adversaries are now manipulating HMI (Human-Machine Interface) displays and falsifying the data operators see on control screens. The operator looks at their dashboard and sees normal. The process is not normal.

The CISA ask is not complicated: remove PLCs from internet exposure, implement MFA on remote access, and monitor OT networks for anomalous behavior. For most water utilities, none of those three controls exist today.

🚨
Hackers brute-forced Dashlane's two-factor authentication and walked out with encrypted password vaults.

Dashlane is a password manager — the tool that stores every username, password, and secure note for an individual or enterprise user behind a single master password and a multi-factor authentication layer.

Over the weekend of June 7–8, attackers brute-forced Dashlane's 2FA system, accessed approximately 20 customer accounts, and downloaded copies of their encrypted password vaults. Dashlane confirmed the breach on their website, specifying that the attackers defeated the MFA mechanism through automated repeated attempts — not by stealing the master password.

The vaults are encrypted, which means the contents are not immediately readable. But that protection depends entirely on the strength of the master password. A stolen encrypted vault plus a weak master password is a solvable problem for a motivated attacker with time and compute.

The practical lesson here is not "don't use a password manager" — it is that MFA is a strong control, not an unconditional one. How it is implemented matters. Rate limiting on authentication attempts, account lockout after failed tries, and hardware security keys as a second factor are measurably more resistant to brute-force than SMS codes or authenticator apps. If your organization manages credentials through an enterprise password manager, confirm what brute-force protections wrap the authentication layer itself — not just the vault.

⚙️
Dragos confirmed adversaries are no longer just getting into OT environments. They are learning how the process works.

The Dragos 2026 OT/ICS Cybersecurity Year in Review is reading differently now that CISA has confirmed active Iranian disruption of U.S. PLCs. The report identified three new threat groups targeting critical infrastructure globally — and the headline finding is not the count. It is the maturity level.

Adversaries are progressing through the ICS Cyber Kill Chain from initial access toward process understanding. A control loop is the automated feedback mechanism that regulates a physical process — pressure, temperature, flow rate, chemical concentration. Mapping a control loop means learning exactly what commands produce what physical outcomes. That knowledge is what separates a nuisance intrusion from a precision attack.

Three groups worth knowing:

KAMACITE — Systematically mapping control loops across U.S. industrial environments. At Stage 2 of the ICS kill chain, meaning active capability development, not just reconnaissance.

PYROXENE — Social engineers posing as recruiters to gain IT access, then pivots into OT. Confirmed infrastructure overlap with IRGC-CEC — the same Iranian command unit behind the water utility PLC campaign above. Also deployed wiper malware against Israeli organizations during the Israel-Iran conflict.

SYLVANITE — Volume-focused Stage 1 group targeting internet-facing OT systems at scale. Initial access specialist that other groups build operations on top of.

The TXOne Networks 2026 report adds the operational context: 96% of OT security incidents originate from IT-level compromises first. The threat gets in through IT. The consequence plays out in OT. Organizations still treating those as separate security programs are leaving the handoff undefended.

ISA/IEC 62443 framing: The Zone and Conduit model exists precisely for this scenario — defining security zones around OT assets and controlling conduits between them. Internet-exposed PLCs with no authentication are a failure at the zone definition level, before a single control is implemented. If your program has not started with a zone-and-conduit architecture review, start there.

🔑
This Week's Term
Prompt Injection

Prompt injection is an attack against an AI system in which an attacker embeds malicious instructions into content the AI is processing — causing the AI to follow the attacker's instructions instead of, or in addition to, the user's.


The term comes from SQL injection, where an attacker inserts database commands into an input field to manipulate what the database executes. Prompt injection does the same thing at the language layer. The attacker does not need to breach the AI system. They just need to get their instructions in front of it through a channel the AI trusts.


Agentjacking this week is prompt injection through an MCP tool integration. The attacker injected instructions into a Sentry error event. The AI agent read the event as data and executed the embedded instructions as commands — because current language models process both as natural language, and the attack was designed to look exactly like legitimate guidance.


Every AI agent with access to external data sources — logs, emails, tickets, error reports, documents — is potentially exposed to prompt injection through any of those channels. You cannot regulate what you do not understand.

📡

Four things to act on before end of week:

01
If your development teams use AI coding agents with Sentry integrated: audit now. Confirm which Sentry DSNs are embedded in public-facing code, review what actions your agents can take autonomously, and require human approval before any agent-initiated code execution. The Agentjacking attack bypasses every technical control except human review of the action itself.
02
Splunk Enterprise on-premises: patch to 10.0.7 or 10.2.4 immediately. If patching is delayed, restrict network access to the Splunk management interface as an interim control and audit who can reach the PostgreSQL sidecar service. Splunk Cloud customers are not affected.
03
ServiceNow customers: pull logs for June 2–5. Look for Guest user account activity and API calls from IP 51.159.98.241. Audit authentication settings on every Scripted REST API endpoint. Rotate any credentials or API tokens stored in affected support workflows.
04
Critical infrastructure operators — especially water utilities: pull CISA Advisory AA26-097A. Inventory every internet-exposed PLC and HMI. If any process control device is reachable from the public internet, that is an immediate remediation. No patch required. Disconnect the exposure.
See you next Tuesday.

— Danielle Peters
Founder, Decode Media

Keep Reading