I go through about 25 cybersecurity news portals and blogs every week and pull out the most interesting stories. Then I turn them into this short, digestible summary, so you can stay up to date without trying to follow 25 different sources yourself. 😱
My aim is to create a summary that gives you the gist without needing to open up the source article. But if you do want to dig deeper, all the sources covering the event are linked below each story.
If you enjoy these, come back next Monday
scroll to the bottom to subscribe to the e-mail newsletter.
1. Vercel incident traced to compromised third-party AI OAuth app used to take over employee Google Workspace account
Vercel reported an incident where a compromise of a third-party AI tool led to takeover of a Vercel employee’s Google Workspace account and access to some internal environments and non-sensitive environment variables.
Vercel is a cloud platform serving 6 million developers across 80,000 active teams, widely used for deploying web applications and increasingly known for v0, its AI-powered vibe coding tool.
Vercel says it has contacted a limited subset of customers whose credentials were compromised, continues investigating possible data exfiltration, and published an indicator to help others detect the same OAuth app in their Google Workspace environments.
Key Details
- Vercel says the incident originated with a compromise of Context.ai, a third-party AI tool used by a Vercel employee.
- The attacker accessed environment variables that were not marked “sensitive”; Vercel says it currently has no evidence that values marked as “sensitive” (stored so they cannot be read) were accessed.
- Vercel initially identified a limited subset of customers whose Vercel credentials were compromised and recommended immediate credential rotation to those customers.
- Vercel published a Google Workspace IOC and recommends admins check for the OAuth client ID 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com.
- Vercel says it engaged Mandiant and other incident response support, notified law enforcement, and states services remain operational while the investigation continues.
Next Steps
- In Google Workspace, immediately check for and remediate usage of OAuth client ID 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com.
- In Vercel, rotate any environment variables that contain secrets but were not marked as “sensitive”, treating those values as potentially exposed.
- Enable and use Vercel “sensitive environment variables” for secret values going forward so they cannot be read.
Read more at Vercel
2. NIST stops automatically enriching most CVEs in the NVD, prioritizing KEV, federal-used, and EO 14028 “critical software” issues
NIST has updated National Vulnerability Database operations so that only three categories of CVEs will receive automatic enrichment (analysis, metadata, and severity scoring): those in CISA's Known Exploited Vulnerabilities (KEV) catalog, those affecting software used by the US federal government, or those classified as "critical software" under Executive Order 14028.
Everything else — including vulnerabilities in software widely used outside the US federal ecosystem — will be listed in the NVD but left unenriched, marked "Not Scheduled."
This matters because unenriched CVEs are effectively invisible to most vulnerability management workflows, which depend on NVD metadata to match vulnerabilities to assets and trigger alerts. The change follows a 263% surge in CVE submissions between 2020 and 2025, and shifts the analysis burden onto CNAs, vendors, and security teams themselves — who must now actively seek out enrichment from alternative sources rather than relying on NVD as a complete, authoritative feed.
Key Details
- Prioritization took effect April 15, 2026, with non-qualifying CVEs marked “Not Scheduled” for automatic enrichment.
- NIST said it enriched nearly 42,000 vulnerabilities last year and reported 2026 Q1 submissions were nearly one-third higher than the same period in 2025.
- Organizations can request attention for exceptions: NIST said users may email nvd@nist[.]gov to request enrichment or reanalysis for specific CVEs when warranted.
Next Steps
- Update vulnerability-management workflows to treat “Not Scheduled” NVD entries as requiring alternate enrichment sources (CNA/vendor advisories, KEV, and your existing threat-intel feeds) rather than waiting on NVD metadata.
- Adjust any automations that depend on NVD-only scoring to ingest CNA-provided CVSS (or equivalent) where present, since NIST may not publish a separate score for those CVEs.
Read more at NIST, BleepingComputer, The Hacker News, Dark Reading, CyberScoop
3. OpenAI rotates macOS code-signing certificates after GitHub Actions workflow pulled malicious Axios package
OpenAI said a GitHub Actions workflow used in its macOS app-signing process downloaded and executed a malicious Axios release during the late-March supply-chain compromise, prompting the company to revoke and rotate its Mac code-signing certificate.
OpenAI reported no evidence of user-data access, compromised internal systems/IP, or altered software, but warned older macOS app versions will lose support/functionality once the old certificate is fully revoked on May 8, 2026.
Key Details
- The Axios maintainer’s npm and GitHub accounts were taken over via social engineering, enabling attackers to publish poisoned Axios versions 1.14.1 and 0.30.4 that were live for about three hours.
- The malicious Axios releases included a fake dependency (“plain-crypto-js”) that delivered the WAVESHAPER.V2 backdoor (reported as cross-platform: Windows/macOS/Linux).
- OpenAI said the affected workflow had access to code-signing certificate and notarization material for ChatGPT Desktop, Codex, Codex CLI, and Atlas; OpenAI described the incident’s root cause as a GitHub workflow misconfiguration.
Next Steps
- Ensure macOS fleets are updated to ChatGPT Desktop 1.2026.071+, Codex App 26.406.40811+, Codex CLI 0.119.0+, and Atlas 1.2026.84.2+ before the May 8, 2026 revocation deadline.
Read more at BleepingComputer, The Hacker News, CyberScoop, Hackread, SecurityWeek
4. 108 malicious Chrome extensions used shared C2 to exfiltrate sessions and inject arbitrary JavaScript
Researchers linked a cluster of 108 Chrome Web Store extensions to a coordinated campaign where all add-ons route stolen credentials, identities, and browsing data to the same command-and-control (C2) backend. The extensions masquerade as games and productivity/Telegram tools but run background code to steal session tokens (including Telegram Web), capture Google identity data via OAuth, and in some cases inject ads or arbitrary JavaScript into pages.
Key Details
- The extensions were published under five identities — Yana Project, GameGen, SideGames, Rodeo Games, and InterAlt — and collectively reached about 20,000 installs in the Chrome Web Store.
- Socket found multiple behavior clusters, including 54 extensions stealing Google account identity via OAuth2 and 45 using a “universal backdoor” that opens arbitrary URLs when the browser starts.
- Five add-ons reportedly used Chrome’s declarativeNetRequest API to strip security headers (e.g., CSP / X-Frame-Options / CORS) from targeted sites to enable injected overlays, ads, or scripts.
- Some extensions exfiltrate Telegram Web sessions repeatedly (e.g., every 15 seconds) and can manipulate session data to replace a victim’s active Telegram session with attacker-supplied session data.
- All 108 were reported to share infrastructure, with the backend hosted at 144.126.135[.]238; campaign-linked developer URLs observed in listings included top[.]rodeo, webuk[.]tech, and interalt[.]net.
Next Steps
- Audit and remove any of the 108 extension IDs from managed browsers using the published list: https://socket.dev/blog/108-chrome-ext-linked-to-data-exfil-session-theft-shared-c2
- Add network controls to block connections to 144.126.135[.]238 and review proxy/DNS logs for contact with top[.]rodeo, webuk[.]tech, and interalt[.]net.
- If any were installed, log out of all Telegram Web sessions from the Telegram mobile app (and remove the extension(s) first).
Read more at The Hacker News, Socket, Cybersecurity News
5. Attackers abuse n8n cloud webhook URLs to host phishing flows, deliver malware, and fingerprint email recipients
Cisco Talos reports threat actors have been abusing n8n-managed cloud webhook URLs (on *.app.n8n[.]cloud) as trusted-looking infrastructure for phishing, including malware delivery and tracking. Because webhook workflows can return web content to the user’s browser (or be triggered by email-client fetches), attackers can make malicious flows appear to originate from a legitimate n8n subdomain.
Key Details
- In one campaign, a “shared document” lure led to an n8n-hosted page showing a CAPTCHA; completing it triggered a malicious payload download from an external host while the browser perceived the flow as coming from the n8n domain.
- A separate pattern used tracking pixels hosted on n8n webhook URLs, causing email clients to send HTTP GET requests with tracking parameters (including the victim’s email address) when messages were opened.
- Abuse has been observed since at least October 2025, leveraging URL-exposed webhooks in the n8n cloud service.
- Talos measured a 686% increase in emails containing n8n webhook URLs in March 2026 compared with January 2025.
- The malware delivery chain aimed to install an EXE or MSI that deploys modified legitimate RMM tools (e.g., Datto and ITarian Endpoint Management) to establish persistence and connect to a C2 server.
Next Steps
- Add detections and email/web filtering rules for unexpected links to *.app.n8n[.]cloud (especially webhook URLs) in inbound mail, and triage messages using “shared document” + CAPTCHA lures.
- Hunt for downloads of EXE/MSI installers followed by installation or execution of RMM tooling (including Datto and ITarian Endpoint Management) originating from these phishing chains.
Read more at The Hacker News
6. Popular note taking app Obsidian community plugins weaponized to trigger cross-platform malware, including new PHANTOMPULSE Windows RAT
Elastic Security Labs tracked a campaign (REF6598) where targets are lured via LinkedIn/Telegram into opening an attacker-controlled Obsidian Sync vault and enabling community plugin sync, after which legitimate Obsidian community plugins are abused to silently execute attacker-defined commands on vault open. The chain delivers Windows malware culminating in a previously undocumented RAT (“PHANTOMPULSE”) and a separate macOS path using an AppleScript dropper with Telegram-based fallback C2 resolution.
Key Details
- Victims are given credentials to an attacker-controlled, cloud-hosted Obsidian vault and instructed to enable community plugin sync, which is disabled by default and requires user action.
- Initial execution is driven by the Obsidian “Shell Commands” plugin, which can run platform-specific commands on triggers like app startup/open; the campaign also used the “Hider” plugin (v1.6.1) to conceal UI elements.
Next Steps
- Consider a policy to disable or tightly govern Obsidian community plugins (especially “Shell Commands”) on corporate endpoints, including guidance that users should not enable “Installed community plugins”/“Active community plugin list” sync from untrusted vaults.
- Add detections/hunts for Obsidian spawning PowerShell and for network activity to 195.3.222[.]251 and panel.fefea22134[.]net (defang/format appropriately for your tooling).
Read more at Elastic Security Labs
7. “Ghost APIs” keep deprecated endpoints live, letting attackers bypass modern auth via forgotten interfaces
The article warns that deprecated API endpoints often remain reachable in production (“Ghost APIs”), creating a gap where systems that are “dead by policy” still work at runtime.
Because these legacy endpoints can predate MFA/zero-trust controls and may be rediscovered via archives or GenAI reconstruction, attackers can use them as an easier path to sensitive data—illustrated by the Optus breach tied to an exposed API endpoint.
Key Details
- Ghost APIs differ from Shadow APIs: Shadow APIs are unknown/undocumented, while Ghost APIs are known endpoints that were marked deprecated and removed from docs but never actually disabled.
- GenAI can reconstruct deprecated endpoint structures quickly using public training data (e.g., old GitHub code, Stack Overflow, archived docs), reducing the effort needed to find and probe old interfaces.
- Attackers commonly surface Ghost APIs via predictable URL/version patterns and archived documentation (e.g., brute-forcing /v1/, /legacy/ and pulling older endpoint maps from the Wayback Machine).
- Older endpoints may still accept weaker auth (static keys/basic auth/older token schemes), which can sometimes be extracted from legacy clients or repositories and used against endpoints that were never upgraded.
- Real-world impact example: Optus (2022)—a customer-data API endpoint was queried without credentials due to an earlier coding error, leading to exposure of 9.5 million records, with regulators later noting missed opportunities to identify and fix the issue.
Next Steps
- Run “scream tests” by disabling a deprecated endpoint for 24–48 hours and monitoring for legitimate breakage before permanent removal.
- Move active APIs to short-lived, identity-scoped tokens (instead of broad long-lived API keys) so legacy endpoints that can’t support modern identity enforcement are naturally cut off.
Read more at Hackread
8. UnDefend PoC shows standard users can prevent Microsoft Defender signature updates by locking definition files
A newly published proof-of-concept dubbed “UnDefend” demonstrates that a non-admin user can block Microsoft Defender from loading updated malware signatures by holding file locks on Defender’s definition/update files. The technique turns Defender’s update flow against itself—updates can download but fail at load time—leaving endpoints stuck on old signatures until the locking process is stopped.
Key Details
- The PoC relies on Windows file-handle sharing/byte-range locks to deny Defender read access to definition files while still allowing Windows Update to write them, causing signature load failures.
- UnDefend attempts multiple independent locking paths, including locking both the active signatures and the last-known-good backup so Defender can’t easily roll back after an update failure.
- It also watches Defender’s definition staging area for changes and then grabs and holds handles to newly modified definition files to prevent the Defender engine from reading them during the update/load step.
- The author notes (but does not publish) an additional capability to misreport Defender “up-to-date” status to EDR/management consoles, implying a path from noisy update failure to stealthy, long-lived degradation.
- Related reporting links the PoC activity to a cluster of recent Microsoft Defender issues/zero-days, including RedSun and BlueHammer, with at least some leaked Windows/Defender zero-days now reported as exploited in the wild.
Next Steps
- If you manage Defender via MDE/Intune/SCCM, add a validation check that compares console-reported signature versions vs. on-disk definition timestamps/versions to catch endpoints that “report green” but aren’t actually updating.
Read more at The Hacker News, CSO Online, Core Security, Nefarious Plan, Nefarious Plan, BleepingComputer
9. Phishers embed fake iPhone purchase lures inside legitimate Apple Account change-alert emails
Attackers are abusing Apple’s Apple ID profile-change notifications to deliver callback phishing lures inside legitimately authenticated emails sent from Apple’s servers. The emails try to scare recipients with a fake “$899 iPhone purchase” claim and push them to call a phone number, where scammers attempt to extract financial info or persuade victims to install remote access software.
Key Details
- The messages were sent from [email protected] and passed SPF, DKIM, and DMARC, indicating they were not simple spoofed emails.
- The attacker creates an Apple ID and inserts the phishing text into user-controlled profile fields (split across first/last name), which Apple then includes in its security notification template.
- To trigger the alert, the attacker changes the account’s shipping information, prompting Apple to email a “your account information was updated” notice that now contains the embedded lure.
- BleepingComputer reports the email appeared to originate from Apple mail infrastructure (including an Apple-owned IP address 17.111.110.47) based on header analysis.
- Header analysis also indicated the original recipient differed from the final delivery address, suggesting the actor may be distributing the messages via a mailing list.
Next Steps
- Update user guidance/runbooks so helpdesks and staff treat Apple alerts that include purchase claims or a “call support” phone number as suspicious, even if the message is authenticated.
Read more at BleepingComputer
Subscribe
Subscribe to receive this weekly cybersecurity news summary to your inbox every Monday.