RSS
Last updated: May 14, 2026 at 10:49 AM UTC
All 219 Vulnerability 76 Breach 45 Threat 91 Defense 7

Federal patch deadline for 13-year-old Apache ActiveMQ flaw is Wednesday - 7,500+ servers still exposed online (CVE-2026-34197)

Federal agencies have until April 30 - this Wednesday - to patch Apache ActiveMQ servers against CVE-2026-34197, a remote code execution flaw that has been hiding in the open source message broker for 13 years. Shadowserver shows more than 7,500 ActiveMQ servers still exposed online and unpatched. The bug normally requires a login, but on ActiveMQ versions 6.0.0 through 6.1.1 a separate older flaw lets attackers skip the login step entirely - making this an unauthenticated remote takeover on those builds. The vulnerability was found using Anthropic's Claude AI assistant by a researcher at Horizon3.ai, who said the discovery was '80% Claude.'

Check
Inventory every Apache ActiveMQ server, including in subsidiary networks and old developer environments, and patch this week before the federal deadline.
Affected
Apache ActiveMQ Classic versions before 5.19.4 and 6.x versions before 6.2.3. CVSS 8.4. ActiveMQ 6.0.0 through 6.1.1 are at acute risk because a separate flaw (CVE-2024-32114) removes the login requirement entirely on those versions, making this an unauthenticated takeover. ActiveMQ Artemis is not affected.
Fix
Upgrade to ActiveMQ Classic 5.19.4 or 6.2.3 (ideally to 5.19.6 or 6.2.5). Change any default admin:admin credentials before exposing the broker again. Hunt broker logs for POSTs to /api/jolokia/ containing 'addNetworkConnector', for unexpected outbound HTTP from the Java process, and for unexpected child processes. Restrict the Jolokia API to internal networks only.

US utility tech giant Itron breached - hackers reached internal IT systems but no impact on the 112 million customer endpoints it manages

Itron, the Washington-based utility technology company that manages 112 million energy and water meter endpoints across 7,700 customers in 100 countries, disclosed a cyberattack in an SEC 8-K filing April 24. An unauthorized third party reached parts of Itron's corporate IT network on April 13. Itron says it has expelled the attackers and seen no follow-up activity, and that customer-hosted environments (the actual utility infrastructure) were untouched. No ransomware group has claimed the attack. The incident is significant because Itron sits in the middle of US critical infrastructure - meter data, billing, and grid telemetry pass through its software at thousands of utilities.

Check
If you work with any utility tech vendor, confirm in writing whether your relationship touches their corporate IT or only their isolated customer-hosted environment.
Affected
Utilities running Itron software, meters, or services - particularly those whose contracts let Itron staff reach into utility systems. Any organization where a critical-infrastructure vendor has remote access without strict segmentation. Itron's segregation of customer-hosted from corporate IT is what limited this incident.
Fix
Review which Itron-side accounts can reach your utility infrastructure and rotate any credentials, API keys, or VPN profiles Itron staff have used since January. Demand a written attestation that customer-hosted environments are network-segregated from corporate IT. Map every critical-infrastructure vendor's reachability into your network, including informal paths.

Medtronic confirms breach after ShinyHunters claims theft of 9 million records and terabytes of internal data

Medtronic, the world's largest medical device maker, confirmed a breach of its corporate IT systems in an SEC filing April 24. ShinyHunters had listed Medtronic on its leak site April 18 claiming theft of more than 9 million records of personal data plus terabytes of internal corporate documents, with an April 21 deadline. The Medtronic listing has since been removed - a strong signal the company either paid the ransom or is still negotiating. Medtronic says product safety, manufacturing, distribution, and patient care are unaffected; the breach was confined to corporate IT, which is segregated from device infrastructure. Investigation into what personal data was exposed is ongoing.

Check
If you or staff have ever been a Medtronic patient, vendor, contractor, or applicant, watch for highly-targeted phishing referencing real medical device or employment details.
Affected
Medtronic patients (90,000+ employees, hundreds of millions of patients), suppliers, and former staff are all in scope until Medtronic clarifies what 9M+ records contain. Healthcare organizations sharing patient data with Medtronic for device monitoring, recall tracking, or research are exposed if those communications are in the leak.
Fix
Affected individuals: enable MFA on patient portals, monitor explanation-of-benefits statements, and report any unsolicited medical-device prompt or service call. Healthcare organizations: pull your data-sharing inventory with medical device vendors and confirm breach-notification SLAs. Companies sharing confidential records with Medtronic should assume those documents may be in the leak set.

CISA and UK NCSC warn 'FIRESTARTER' backdoor survives Cisco ASA/Firepower patches - US agency compromised, hardware replacement recommended

CISA and the UK's National Cyber Security Centre jointly published a malware analysis report for FIRESTARTER, a persistent backdoor that China-linked group UAT-4356 (the same crew behind 2024's ArcaneDoor campaign) planted on Cisco ASA and Firepower firewall devices by chaining CVE-2025-20333 (VPN web server RCE) and CVE-2025-20362 (unauthorized access). The implant hooks into Cisco's Service Platform mount list, a boot-time configuration that controls which programs run when the device starts, so it survives reboots, firmware upgrades, and the September 2025 patches for those two CVEs. CISA found FIRESTARTER on an already-patched US federal civilian agency's Cisco Firepower device through continuous network monitoring - attackers silently returned in March 2026 to deploy a second-stage implant called Line Viper without needing to re-exploit the original vulnerabilities. Updated Emergency Directive ED 25-03 now orders federal agencies to audit every Cisco ASA and Firepower device they run and submit device memory snapshots for CISA analysis. The stark guidance for everyone else: if you confirm a compromise, replace the hardware. Reimaging is not enough because the bootloader itself may be implanted.

Check
Inventory every Cisco ASA and Firepower Threat Defense device in your environment - including branch offices, remote sites, and lab gear - and check patch status against CVE-2025-20333 and CVE-2025-20362 as the absolute minimum baseline.
Affected
Cisco Adaptive Security Appliance (ASA) and Firepower Threat Defense (FTD) devices running ASA/FTD software, particularly any units that were internet-exposed and unpatched between the September 2025 patch release and the date you actually applied it. Devices patched in that window may still carry the FIRESTARTER implant because the backdoor survives patching.
Fix
Patch any ASA/FTD device still vulnerable to CVE-2025-20333 or CVE-2025-20362 immediately. Then perform a core dump on every device following CISA's supplemental direction and look for FIRESTARTER indicators described in MAR AR26-113A and the joint advisory AA26-113A. Any device showing indicators of compromise must be replaced with new hardware - do not trust reimaging or factory reset, because the persistence mechanism modifies the Cisco Service Platform mount list and the bootloader may be affected. Rotate all VPN credentials and admin passwords on affected devices. Hunt for Line Viper and review firewall logs for unexpected outbound connections from management interfaces for the period after initial patching.

Carnival confirms 7.5 million Holland America Mariner Society loyalty records leaked after ShinyHunters refused extortion deadline

Carnival Corporation has been confirmed as a ShinyHunters breach victim, and the data is now public. Have I Been Pwned added the breach on April 23 with 7,531,359 unique email addresses drawn from 8.7 million records. The data comes from the Mariner Society loyalty program operated by Holland America Line, one of Carnival's cruise brands, and contains full names, dates of birth, genders, email addresses, and loyalty program status fields. ShinyHunters initially listed Carnival on its 'pay or leak' portal on April 18 with an April 21 deadline alongside Zara, 7-Eleven, and roughly 40 other organizations. When Carnival did not pay, the group published the dataset on its leak site this week. Carnival confirmed to reporters that the initial access came from a phishing compromise of a single employee account - a reminder that ShinyHunters continues to rely on human-layer intrusion rather than novel exploits. For anyone whose email, date of birth, or customer record appears in the dataset, the immediate risk is highly targeted phishing and account-takeover attempts that reference genuine Holland America booking details.

Check
If your organization has ever done corporate bookings, incentive travel, or employee perks through Holland America, Princess, or other Carnival brands, notify affected staff today and watch for cruise-themed phishing referencing genuine loyalty-program details over the coming weeks.
Affected
Anyone who has a Mariner Society loyalty account with Holland America Line, and by extension anyone who has booked a Holland America cruise through loyalty channels. The exposed fields (name, date of birth, email, gender, loyalty status) are foundational identity data - strong enough to power convincing impersonation, knowledge-based authentication bypass, and targeted spear-phishing.
Fix
Check Have I Been Pwned to confirm whether your address is in the Carnival dataset. If it is, watch for phishing emails pretending to be from Holland America or other Carnival brands that reference your real past bookings or loyalty tier - treat any such message as hostile and navigate to the Holland America site directly rather than clicking links. Rotate passwords on any account that shares a password with Mariner Society. At an organizational level, add 'holland-america.com' and 'hollandamericafund.com' lookalike domains to your DMARC and brand-monitoring watchlists, and brief travel-desk staff that any Mariner Society outreach should be verified by phone.

CISA adds actively-exploited Microsoft Defender 'BlueHammer' flaw to KEV as two sibling zero-days (RedSun, UnDefend) remain unpatched (CVE-2026-33825)

CISA added CVE-2026-33825 to its Known Exploited Vulnerabilities catalog on April 23 with a May 7 federal patch deadline. The flaw, nicknamed BlueHammer, is a race condition in Windows Defender's file-remediation logic that lets an unprivileged local attacker overwrite arbitrary files on disk and escalate to SYSTEM on fully-patched Windows 10 and Windows 11 hosts. It was patched in Microsoft's April 8 Patch Tuesday but a working proof-of-concept had already been published to GitHub by a researcher called 'Chaotic Eclipse' on April 7, before the fix shipped. Huntress Labs saw in-the-wild exploitation from April 10, with attackers also picking up two sibling Defender zero-days the same researcher leaked: RedSun (another local privilege escalation) and UnDefend (a denial-of-service that blocks Defender from pulling security definition updates, effectively disarming the EDR). Those two still have no Microsoft patch. The combination - a working privilege-escalation path plus an unpatched technique to silently cripple Defender itself - makes this a priority hunt, not just a priority patch.

Check
Verify that every Windows 10 and Windows 11 endpoint in your fleet has the April 2026 Patch Tuesday update installed and then hunt for the BlueHammer/RedSun/UnDefend technique patterns in your EDR telemetry.
Affected
Windows 10 and Windows 11 endpoints that have not installed the April 8, 2026 Patch Tuesday cumulative update. Note that patching closes BlueHammer (CVE-2026-33825) only - RedSun and UnDefend remain unpatched at time of writing, so patched hosts are still exposed to local privilege escalation via RedSun and to Defender disablement via UnDefend.
Fix
Deploy the April 2026 Patch Tuesday update (which addresses CVE-2026-33825) to every Windows endpoint and verify coverage against MDM or configuration-management inventory rather than trusting WSUS compliance alone. For the two unpatched sibling flaws, tighten EDR rules to alert on: anomalous file writes to Defender-controlled paths, unexpected changes to Defender signature update behavior, and any process attempting to stop or starve MsMpEng.exe. Treat any host where Defender has not received a signature update in over 48 hours as suspicious until proven otherwise. Review Huntress's public IoCs for the three techniques.

Attackers actively exploiting critical unauthenticated file upload flaw in Breeze Cache WordPress plugin on 400,000 sites (CVE-2026-3844)

Wordfence has seen more than 170 live exploit attempts against CVE-2026-3844, a critical unauthenticated arbitrary file upload in the Breeze Cache WordPress plugin from Cloudways. Breeze has roughly 400,000 active installations, making this one of the larger exposure events of the month. The flaw lives in the fetch_gravatar_from_remote function, which fetches avatar images from an arbitrary remote URL and saves them locally without validating the downloaded file's MIME type - so an attacker can point it at a .php payload and drop a webshell directly into a web-accessible directory. The attack is only possible when the 'Host Files Locally - Gravatars' add-on is enabled, which is not the default, but any site that turned it on for performance reasons is wide open. Cloudways shipped the fix as Breeze 2.4.5 earlier this week; as of publication only about 138,000 of the 400,000 installations had downloaded the patched version, leaving hundreds of thousands of sites exposed to a pre-auth RCE with 9.8 CVSS.

Check
Check every WordPress installation you run or manage (including marketing microsites, staff personal sites on corporate subdomains, and legacy tenant sites) for the Breeze Cache plugin and its version.
Affected
Breeze Cache WordPress plugin versions 2.4.4 and earlier, but only when the 'Host Files Locally - Gravatars' sub-feature has been enabled. CVSS 9.8. Discovered by security researcher Hung Nguyen (bashu). If you do not run that sub-feature the plugin is not currently exploitable via this bug, but the fix should still be applied immediately.
Fix
Update Breeze Cache to version 2.4.5 immediately across every site that uses it. If you cannot update straight away, disable the 'Host Files Locally - Gravatars' option or temporarily deactivate the plugin entirely. After patching, hunt the site's wp-content/uploads/cache directory and similar writable paths for recently-created .php files and files with mismatched MIME types, check for new WordPress admin users, and review web server logs for POSTs to the Breeze gravatar endpoint from the exploitation window. Confirm no webshell has been planted before declaring the site clean.

'Shai-Hulud: The Third Coming' worm pivots from Checkmarx KICS compromise into Bitwarden CLI, stealing SSH keys, cloud secrets, and MCP configs for AI coding tools

TeamPCP's self-propagating supply-chain worm is back in its third iteration, branded 'Shai-Hulud: The Third Coming' in hard-coded strings across the malware. On April 22, Socket reported Checkmarx's official KICS Docker images and a KICS VS Code / Open VSX extension had been trojanized. Bitwarden's own clients repo runs a Checkmarx scan on every pull request via a pull_request_target workflow that holds id-token: write and fetches credentials from Azure Key Vault, so when the poisoned scanner executed it harvested GitHub OIDC and Azure tokens. At 17:57 ET the same day, attackers used those tokens to push a modified publish-cli.yml to the Bitwarden repo and publish a malicious @bitwarden/cli version 2026.4.0 to npm. The package remained live for 93 minutes until Bitwarden pulled it at 19:30 ET. The payload: a 10MB obfuscated credential harvester that grabs SSH keys, cloud provider credentials, npm publish tokens, GitHub tokens, and - new in this variant - MCP (Model Context Protocol) configuration files used by Claude Code, Cursor, and similar AI coding tools. It then self-propagates by republishing into every npm package the victim can modify and uploads encrypted stolen secrets to public GitHub repositories under Dune-themed names. The worm has a Russian-locale kill switch (exits if LC_ALL/LANG starts with 'ru').

Check
Immediately check every CI/CD runner, developer laptop, and container that pulled Checkmarx KICS Docker images, the KICS GitHub Action, or @bitwarden/cli between March 23 and April 23, and rotate every credential that was ever present on those machines.
Affected
Confirmed malicious artifacts per Socket: @bitwarden/cli 2026.4.0 on npm (live 21:57 to 23:30 UTC on April 22, a 93 minute window); compromised Checkmarx KICS Docker images and GitHub Actions (first compromised March 23, re-compromised April 22); two Checkmarx-published Visual Studio Code and Open VSX extensions. Any npm package subsequently republished by a victim whose npm token this worm captured is also potentially malicious.
Fix
Remove the listed versions from all developer environments, CI runners, and private mirrors. Rotate every credential the worm would have seen: GitHub PATs and OIDC tokens, npm publish tokens, cloud provider keys (AWS/GCP/Azure), SSH keys, Azure Key Vault secrets, container registry creds, and MCP config files for AI coding tools - assume every credential stored in ~/.config, ~/.ssh, or exported to CI env is burned. Audit bitwarden/clients commit history for changes to publish-cli.yml and similar pipeline files around April 22. Search public GitHub for repositories named after Dune terms (beautifulcastle-* pattern) to find whether your stolen data has been published. Tighten pull_request_target triggers on security scanners - they should not have id-token: write permission.

Lovable 'vibe coding' platform exposed source code, Supabase credentials, and AI chat history for 76 days via missing ownership check in API

Security researcher @weezerOSINT disclosed on April 20 that Lovable, the Swedish AI code-generation platform that just raised a $330M Series B at a $6.6B valuation, had a Broken Object Level Authorization flaw letting any free account read another user's project source code, hardcoded database credentials, AI chat transcripts, and customer data - using only five API calls. The /projects/{id}/* endpoints verified Firebase authentication but skipped any ownership check. On April 23 Lovable published a formal incident report admitting the exposure window ran February 3 to April 20, a full 76 days, caused by a backend regression that silently undid a fix shipped in 2025. Every Lovable project created before November 2025 was readable. The researcher demonstrated the impact by pulling source code from Connected Women in AI, a Danish nonprofit with over 3,700 edits in 2026 alone, extracting hardcoded Supabase credentials from that code, then querying the live database to retrieve real names, LinkedIn profiles, and Stripe customer IDs belonging to Accenture Denmark and Copenhagen Business School staff. Lovable's initial public response was to deny a breach occurred and blame its documentation and HackerOne triage partner before eventually apologizing.

Check
If your team or any staff member has ever built anything on Lovable (including experimental internal tools, prototypes, and hackathon projects) treat every secret that was ever in a Lovable project or chat as potentially public.
Affected
Any Lovable project created before November 2025 was readable by any other Lovable user between February 3 and April 20, 2026. That includes source code (which Lovable commonly generates with hardcoded Supabase anon keys and service role keys), AI chat histories (which often contain pasted API keys and config values), and any customer data stored in the project's connected Supabase database.
Fix
Rotate every Supabase anon key and service role key associated with any project you ever built on Lovable, plus any third-party API key that was ever pasted into a Lovable app, chat, or prompt - Stripe, Resend, SendGrid, OpenAI, Anthropic, and so on. Enable Row Level Security on every table in every connected Supabase project and review each policy by hand. Pull the last 90 days of Supabase audit logs and search for anomalous reads. Export and archive anything you need out of Lovable, remove sensitive values from chat history, and watch for Lovable's direct email notifying affected projects. For EU personal data, open the GDPR breach notification process.

Vercel expands Context.ai breach scope - additional accounts compromised, and some predate the April incident entirely

Vercel updated its security bulletin on April 23 to disclose that ongoing forensics has uncovered additional customer accounts compromised in the Context.ai-linked breach that went public on April 19, and - more worryingly - a separate cluster of customer accounts with evidence of compromise that predates and appears unconnected to the Context.ai incident. CEO Guillermo Rauch confirmed on X that the threat actor has been active beyond Context.ai's compromise. Hudson Rock's forensic report traced patient-zero to a Context.ai employee whose laptop was infected by Lumma Stealer in February 2026 after downloading Roblox auto-farm scripts - a roughly four-week dwell time before the operator pivoted into Context.ai's AWS environment and then through OAuth tokens into Vercel's Google Workspace. The stolen credential set from that single laptop included Google Workspace logins, Supabase keys, Datadog tokens, Authkit credentials, and the support@context.ai account. Vercel has now confirmed non-sensitive environment variables in affected team scopes were readable to the attacker, and says customer notifications are going out individually rather than via a public list.

Check
If you run any service on Vercel, re-check your team's incident email for new direct notifications, and proactively rotate any environment variable not marked as 'sensitive' that was stored in Vercel during February to April 2026.
Affected
Vercel customer teams where a member authorized Context.ai's AI Office Suite OAuth integration against a Vercel enterprise Google Workspace account, and any Vercel team with environment variables not explicitly marked as 'sensitive' stored during the February to April 2026 window. The newly-surfaced predate-April account cluster is separate and Vercel has not publicly scoped it - if you receive a notification email, treat it as a distinct compromise and not simply a continuation of the Context.ai incident.
Fix
Rotate every environment variable stored in Vercel that was not marked as 'sensitive' - in practice, treat every database URL, API key, signing secret, and third-party credential as public and rotate it in place. Audit Google Workspace OAuth app grants and revoke any Context.ai 'AI Office Suite' integration. Review Vercel activity logs back to February 2026 for unexpected access to environment variable dashboards. Rotate Supabase, Datadog, and Authkit credentials if any Context.ai employee or integration ever had access to yours. Set a standing policy that no OAuth grant from an external AI tool gets 'Allow All' Workspace permissions.