Last updated: August 19, 2026 at 1:47 AM UTC
All 741 Vulnerability 286 Breach 129 Threat 319 Defense 7
Tag: code-injection (3 articles)Clear

Google patches Dialogflow flaw that let one chatbot hijack others in a project

Varonis disclosed a now-patched flaw in Google Cloud's Dialogflow CX, the platform many companies use to build customer-service, financial, and healthcare chatbots. Because all chatbots using the platform's custom-code feature in one Google Cloud project shared a single execution environment with a writable setup file and no isolation, an attacker who could edit one agent, needing only a single low-level permission, could overwrite that file and hijack every chatbot in the project. From there they could read live conversations, steal shared data, and make bots ask for passwords. Google reported no exploitation before fixing it and no customer action is now required, but the case shows how AI features inherit cloud risks.

Check
If you used Dialogflow CX with custom Code Blocks, review the Dialogflow audit logs for unexpected playbook updates, check who held the update permission, and confirm each agent's code blocks are approved.
Affected
Organizations that built Dialogflow CX agents with custom Code Blocks before Google's fix; an attacker with edit rights on one agent could take over every agent in the same Google Cloud project.
Fix
No action is needed now that Google has fixed the flaw, but review historical audit logs if you used the feature, and more broadly scope AI-platform permissions tightly and isolate sensitive agents.

6,400 exposed Apache ActiveMQ servers still vulnerable to actively exploited CVE-2026-34197 - ShadowServer data shows Asia most impacted

Day-after follow-up to our April 18 coverage: Shadowserver has published telemetry showing 6,400+ Apache ActiveMQ servers exposed online are still vulnerable to CVE-2026-34197, the 13-year-old code injection flaw CISA added to KEV last week with an April 30 federal patch deadline. Geographic breakdown: Asia leads with 2,925 vulnerable servers, North America follows at 1,409, Europe at 1,334. Horizon3's Naveen Sunkavally (who discovered the flaw using the Claude AI assistant as his research tool) is urging admins to treat this as high priority, noting ActiveMQ has been a repeated target for real-world attackers - CVE-2016-3088 and CVE-2023-46604 are both on KEV, with the latter used as a zero-day by the TellYouThePass ransomware gang. The Apache maintainers patched the flaw on March 30 in ActiveMQ Classic 6.2.3 and 5.19.4. Horizon3 recommends searching broker logs for suspicious connections using the internal VM transport protocol with the brokerConfig=xbean:http:// query parameter as an indicator of exploitation.

Check
If you haven't patched ActiveMQ since March 30, check now. ShadowServer data shows thousands of exposed servers are still unpatched two weeks after the advisory.
Affected
Apache ActiveMQ Classic versions 5.x before 5.19.4, and 6.0.0 before 6.2.3, with the Jolokia JMX-HTTP bridge exposed via the web console at /api/jolokia/. ShadowServer identifies 6,400+ internet-exposed vulnerable instances as of April 20.
Fix
Upgrade to ActiveMQ Classic 5.19.4 or 6.2.3. For retroactive detection, search broker logs for connections using the internal VM transport protocol combined with the brokerConfig=xbean:http:// parameter - this pattern indicates an exploitation attempt regardless of success. If an exploit signature is found, treat the broker host as potentially compromised and rotate all credentials that passed through it.

13-year-old Apache ActiveMQ code injection flaw actively exploited - CISA gives federal agencies until April 30 to patch (CVE-2026-34197)

A critical code injection flaw in Apache ActiveMQ Classic has been under active exploitation in the wild, and CISA added it to the Known Exploited Vulnerabilities catalog on April 16 with a federal patch deadline of April 30. The flaw, tracked as CVE-2026-34197 (CVSS 8.8), has been 'hiding in plain sight' for 13 years according to Horizon3.ai researcher Naveen Sunkavally. The vulnerability is in the Jolokia JMX-HTTP bridge exposed at /api/jolokia/. An attacker can send crafted HTTP requests with a malicious discovery URI that forces the broker to load a remote Spring XML configuration. Because Spring initializes beans before validation, attackers execute arbitrary OS commands via Runtime.exec() - effectively turning a messaging broker into a remote command runner. Fortinet FortiGuard Labs telemetry shows exploitation attempts peaking on April 14, 2026. SAFE Security reports threat actors actively scanning for exposed Jolokia management endpoints.

Check
Inventory every ActiveMQ instance in your environment. If you don't know whether you run ActiveMQ, check with your dev team - it's embedded in many enterprise messaging pipelines and IoT data flows.
Affected
Apache ActiveMQ Classic versions 5.x before 5.19.4, and 6.0.0 before 6.2.3. The vulnerable component is the Jolokia JMX-HTTP bridge exposed via the web console at /api/jolokia/. Any internet-exposed ActiveMQ broker with default Jolokia configuration is at risk.
Fix
Upgrade to Apache ActiveMQ 5.19.4 or 6.2.3. If you cannot patch immediately: block external access to the /api/jolokia/ endpoint at your firewall or reverse proxy, restrict the Jolokia policy to specific MBeans only (not the default org.apache.activemq:* wildcard), and require authentication for all management operations. Check your access logs for HTTP requests to /api/jolokia/ with suspicious URI parameters over the past 30 days - exploitation requires only one successful request.