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.
EvilFontTool PoC uses remapped font glyphs to make documents display one message to humans and different text to machines
A proof-of-concept toolkit called EvilFontTool demonstrates how maliciously remapped font glyphs can make a document visually say one thing while the underlying text read by terminals, AI systems, and copy/paste says another. The approach enables “what you see is not what you copy/parse” deception without changing the document’s visible appearance to the reader.
Key Details
- The technique relies on “evil fonts” that intentionally render a different character than the one encoded in the text, by remapping glyphs in the font.
- The project is positioned as demos and proof-of-concepts rather than a disclosed in-the-wild campaign.
- It specifically calls out divergence between what a person sees and what terminals, AI systems, and clipboard copy/paste interpret from the same content.
Read more at Talkback.sh, github.com
Salesforce Agentforce flaw let attackers exfiltrate CRM data via indirect prompt injection and a CSP allowlist bypass
Researchers disclosed “ForcedLeak,” a critical (CVSS 9.4) vulnerability chain in Salesforce Agentforce that could leak sensitive CRM data by planting malicious instructions in Web-to-Lead submissions that were later processed by employees’ AI-agent workflows. Salesforce shipped mitigations that block Agentforce output from being sent to untrusted URLs, addressing the exfiltration path used in the proof-of-concept.
Key Details
- Attack precondition: Web-to-Lead enabled; attackers submit a lead containing hidden instructions (primarily via the high-character “Description” field) that are stored and later retrieved into the agent’s context.
- The chain relied on trust-boundary confusion in agent context: the model treated attacker-supplied lead text as executable instructions when employees asked the agent to review/respond to the lead.
- A critical step was a Content Security Policy (CSP) bypass using an expired but whitelisted domain (my-salesforce-cms[.]com), enabling outbound requests that carried exfiltrated data.
- Proof-of-concept exfiltration used an HTML image request with CRM data embedded in URL parameters, causing the browser to send the data to attacker infrastructure when rendering the agent’s output.
- Salesforce re-secured the expired domain and introduced Trusted URLs Enforcement for Agentforce and Einstein AI (mitigation dated September 8, 2025), followed by public disclosure on September 25, 2025.
Next Steps
- Apply Salesforce’s guidance to enforce Trusted URLs for Agentforce and Einstein AI (and verify untrusted URL egress is blocked): https://help.salesforce.com/s/articleView?id=005135034&type=1
- If you use Web-to-Lead, audit existing lead records (especially “Description”) for embedded instructions or unusual formatting consistent with indirect prompt-injection payloads.
- Review any CSP / allowlist approach for AI-agent output rendering and ensure no expired or unowned domains remain trusted
- Review any pipelines where AI processes input from outside parties - webforms, e-mails etc. for potential prompt-injection vulnerabilities.
Read more at noma.security, CSO Online
Mini ‘Shai-Hulud’ npm worm spreads via stolen publisher tokens after Keyv maintainer compromise, poisoning 400+ packages
Attackers compromised the maintainer account behind the widely used Keyv npm library and used that access to publish malicious updates that install credential-stealing code through normal dependency installs. Microsoft and Socket described it as a self-propagating npm supply-chain campaign that steals and reuses publishing tokens to spread to additional packages.
Key Details
- Socket reported the incident had grown to 2,234 affected package artifacts across 444 unique packages while the activity was still spreading. Combined, the packages have millions of downloads every week.
- Microsoft Threat Intelligence said the actor compromised trusted maintainer accounts and used multiple stolen publishing tokens to distribute the malware.
- The malicious releases were designed to run at install time, meaning developers and CI/build systems could be impacted simply by installing dependencies.
- Post-install behavior described in the reporting included hunting for npm, code-hosting, cloud, and CI-related credentials and exfiltrating them for further propagation.
Next Steps
- Identify and remove any affected packages/versions in your dependency tree and rebuild lockfiles from a known-good state (avoid reusing potentially poisoned lockfiles).
- For publishing and release automation of maintained npm packages, require MFA and move to short-lived, narrowly scoped tokens (and separate build permissions from publish/release permissions where possible).
Read more at Cyber Security News, Cyber Security News, Socket.dev, Talkback.sh, The Hacker News
WebKit proxy bypass leaks real IP and DNS outside iCloud Private Relay via DNS prefetch, WebAuthn, and WebTransport
Researchers found that three WebKit features can bypass app-level proxy settings and Apple’s iCloud Private Relay, causing some connections to go directly from the device instead of through the intended proxy path. The leaks occur when a page triggers DNS prefetching, WebAuthn “related origin” validation fetches, or WebTransport connections—allowing sites to learn a user’s real network IP and/or DNS resolver even when Safari Private Relay (or an iOS “proxy browser,” including Tor-style browsers) is enabled.
Key Details
- DNS prefetching can reveal a user’s real DNS resolvers by resolving attacker-controlled hostnames via the device’s normal DNS path instead of the configured proxy/Private Relay.
- WebAuthn Related Origin Requests can expose the device’s real IP because the OS credential service (not the browser’s proxied network stack) fetches the required validation resource directly from the device.
- WebTransport (HTTP/3/QUIC) can expose the device’s real IP because the connection is established outside the session’s proxy configuration and is not carried through Private Relay.
- Scope: affects WebKit-based proxy browsers on iOS/macOS that rely on
WKWebsiteDataStore.proxyConfigurations(including iOS Tor-style browsers) and also impacts Safari with iCloud Private Relay; VPNs are not affected because they tunnel traffic at the system level. - Psylo 1.3.1 mitigates the leaks by blocking
dns-prefetchhints and disabling WebTransport and WebAuthn by default, with per-site (per-silo) opt-in toggles for functionality that users need.
Next Steps
- Use leaks[.]psylo[.]app to validate whether your current iOS/macOS WebKit-based proxy setup (including Private Relay) is leaking IP/DNS via these mechanisms.
- For stronger anonymity, use a reputable VPN provider.
Read more at Mysk Blog – In-Depth Cybersecurity & Mobile App Privacy Research, Talkback.sh, Cybersecurity Reddit, The Hacker News, Cyber Security News, 404 Media
Linux Foundation opens SAFE RFC for confidential sharing of agentic AI incident and near-miss data
The Linux Foundation issued an RFC for the Shared AI Findings Exchange (SAFE), a proposal to standardize confidential reporting and analysis of AI agent incidents, misbehavior, and near misses so findings can be turned into evidence-based recommendations. The draft was produced by the Open Secure AI Alliance (now over 120 members) and follows recent disclosures of models “going rogue” in tests, including sandbox escapes and real-world impact when a test system was internet-connected.
Key Details
- Comments on SAFE are being collected on GitHub under the Open Secure AI Alliance RFCs repository.
- SAFE’s workflow includes notifying affected parties and identifying recurring control failures across submitted incidents, with recommendations based on incident evidence rather than vendor guidance.
- The alliance says it has grown from ~two dozen founding members (July 27) to 120+ organizations; Anthropic, OpenAI, and Google are noted as not having joined (per SiliconANGLE).
- Member contributions include tools intended to harden and test AI agents, such as Nvidia’s Garak (LLM vuln scanning) and OpenShell (agent-restricting runtime), Microsoft’s PyRIT and RAMPART, Okta’s Cross App Access (XAA) implementations, and Red Hat’s Asago mapping governance requirements (e.g., EU AI Act) to runtime controls.
- Uber contributed ADR (agentic AI detection and response), which reconstructs an agent’s causal chain of actions and is reportedly run across more than 200,000 agent sessions per day (per SiliconANGLE).
Next Steps
- Read more GitHub RFC process: https://github.com/OpenSecureAIAlliance/RFCs
Read more at Talkback.sh, SiliconAngle
CSS-in-email “boundary breakouts” let messages manipulate webmail UI and leak passwords and tokens across major providers
New research shows that CSS and HTML inside emails can escape the message sandbox and interfere with trusted webmail UI, enabling spoofed sign-in prompts, token exfiltration, and unintended UI actions across Outlook, Gmail, Yahoo/AOL, Fastmail, and Proton Mail. The techniques rely on allowed CSS/HTML features and sanitizer/browser parsing discrepancies that let attacker-controlled styling influence or trigger actions outside the email content area.
Key Details
- Outlook (web) + Firefox PoC: allowed
- Yahoo Mail/AOL Mail “paste race” in Firefox: HTML briefly retained active CSS before sanitization when pasted into a draft, allowing a Medium email-login flow to leak enough of a 12‑character login token via outbound requests for the attacker to reconstruct and reuse.
- CSP-bypassing click exfiltration: when external loads are blocked, injected CSS can filter page links based on which digits appear in a rendered numeric token and encode digit/frequency data into the one remaining clickable link a victim is likely to press.
- Gmail + Claude “Cowork” chain: Gmail’s image-set() fallback was used to force an external request despite sanitization, then combined with an indirect prompt-injection email processed via a Gmail connector to place a Slack token into an HTML draft that leaked when viewed.
- Fix/works-as-tested status (as published): Fastmail fixed two CSS mutation bugs; a Proton Mail proxy bypass reportedly stopped working on retest; Outlook “label-jacking” and Gmail’s image-set() bypass were still working when the research was published, and public PoCs were available (GitHub: portswinger/css-the-bomb-inside-your-inbox).
Next Steps
- Review whether your org enables AI email connectors/agents that can read inbox contents (e.g., Gmail connectors) and restrict them to least-privilege scopes and trusted workflows until you validate how they handle HTML email and draft rendering.
- For webmail providers and product teams: isolate HTML email in a sandboxed iframe and tightly restrict CSS (including custom attributes, select menus, and attacker-controlled image requests), per the paper’s recommended defensive approach.
Read more at The Hacker News, Talkback.sh, Dark Reading
OWASP GenAI LLM Top 10 (2026) updates rankings using 7,714 real AI security incidents and adds deeper coverage for agentic risks
OWASP released the 2026 edition of its GenAI/LLM Top 10, a community-driven guide that ranks the most critical risks in LLM-powered applications using practitioner input and an incident-backed dataset. The guide emphasizes that teams should harden the surrounding application architecture so failures in the model are contained, and includes practical attack scenarios, mitigations, and mappings to major security frameworks.
Key Details
- The 2026 rankings are grounded in an empirical dataset of 7,714 AI-related security incidents (6,639 had enough detail to classify), combined with community voting (~75% voting / 25% incident data).
- Prompt Injection remains LLM01 because any path where a model ingests untrusted text is an ongoing attack surface, even if public exploit examples are still relatively limited.
- Appendix A provides cross-framework mappings to OWASP (including the Top 10 for Agentic Applications), NIST guidance (AI RMF and related profiles), MITRE (ATLAS/ATT&CK/CWE), and the CSA AI Controls Matrix to integrate LLM risks into existing security programs.
Read more at OWASP Gen AI Security Project, Cyber Security News
XCSSET v40 resurfaces on macOS with fileless, memory-resident core and a Chrome DevTools–based browser hijack
XCSSET malware has returned with v40, spreading via trojanized Xcode projects so infection triggers when developers build affected code locally, then loads its core logic into memory and deletes on-disk artifacts. The new release adds modules including a Chrome hijacking backdoor that abuses the Chrome DevTools Protocol (CDP) to run attacker JavaScript inside the legitimate browser process and steal session data.
Key Details
- Supply-chain delivery via Xcode projects and GitHub repos: attackers injected loader scripts into benign project files; v40 can now infect all existing Xcode projects on a compromised system (“worming” behavior).
Next Steps
- Audit Xcode projects and build pipelines for unexpected injected scripts/obfuscation, especially in projects sourced from public repos; re-clone from known-good commits if tampering is suspected.
- On macOS developer endpoints, hunt for CDP-enabled Chrome launches (Chrome started with remote-debugging/CDP flags and an unusual local port) and investigate any wrapper/persistence around the Chrome app binary.
Read more at Talkback.sh, Cyber Security News
Prompt-injection via a planted X comment let researchers hijack ChatGPT Atlas to spam WhatsApp contacts and place an Amazon order
Zenity Labs demonstrated that a single malicious social-media post could trigger prompt-injection that steered ChatGPT’s Atlas browser agent into taking unintended actions on a user’s behalf. The proof-of-concept shows how agentic “browse and act” features can be manipulated through untrusted web content to perform real-world fraud and outbound messaging from within a user’s logged-in sessions.
Key Details
- Attack chain started from an attacker-planted X (Twitter) comment that Atlas encountered while browsing, supplying instructions that overrode the user’s intent.
- Actions executed inside the victim’s authenticated context, enabling the agent to message WhatsApp contacts and make an Amazon purchase using stored/payment-on-file details.
- The technique is a practical example of indirect prompt injection, where instructions are embedded in third-party content the agent reads (as opposed to being typed by the user).
- Impact is driven by tool access (browser automation), not model “secrets”: once an agent can click, type, and submit forms, injected instructions can translate into transactions and messages.
Next Steps
- Constrain agent permissions by disabling/limiting “take actions” modes for high-risk sites (messaging, ecommerce, payments) unless a user explicitly enables them for that session.
- Require step-up confirmation for irreversible actions (sending messages, placing orders, changing account settings) so agents can browse/summarize but can’t commit without a clear user approval gate.
- Block or strip untrusted instruction-bearing content in agent sessions (e.g., don’t let agents follow or act on social feeds/comments by default) and provide a curated allowlist of domains agents may act on.
Read more at Zenity Labs, Wired Security
Apple caps bug bounty submissions after surge of AI-hallucinated vulnerability reports
Apple has limited how many vulnerability reports a researcher can have in its bug bounty program after a wave of low-quality, AI-generated submissions that made it harder to surface legitimate findings. The change follows a surge of reports attributed to AI “hallucinations,” and Apple has also started using AI to help triage incoming submissions.
Key Details
- The new restriction was introduced after a spike in low-quality reports generated with AI tools that “bury” real vulnerability findings.
- Cybersecurity firm Bynario said it hit the new cap after using ChatGPT to identify more than 50 macOS issues.
- Bynario reported it had a privilege-escalation exploit it could not immediately submit because of the cap.
- Researchers can request higher submission limits under the updated approach.
- Apple has begun using AI to help triage submissions amid the increased volume.
Read more at Talkback.sh, ft.com
tl;dv meeting assistant exposed cross-tenant Firestore “meetings” data, enabling unauthenticated enumeration and live-call joining via leaked conference IDs
Reporting described how tl;dv’s backend allowed any authenticated tl;dv user to query a Firestore “meetings” collection across all customers, exposing meeting metadata including creator emails and joinable conference IDs. Because active meetings were visible with a “recording” status, the issue could be used to identify live calls in near real time and join them without an invitation.
Key Details
- Scale reported: 181,874 meeting records tied to 84,312 unique users across 35,003 email domains, including .gov and .edu usage.
- Live-call exposure mechanism: meeting records included conference IDs (Google Meet/Teams) and status; the report claimed ~1,000 meetings at any time had status “recording,” enabling opportunistic joining.
- Public content exposure: after checking 27,334 meeting IDs, the report claimed 1,000+ meetings were publicly accessible and exposed 715 invitee emails across 228 domains.
- Disclosure timeline claim: the researcher said they notified tl;dv in late January 2026 and that the Firestore access issue remained unfixed as of July 2026.
Next Steps
- Restrict meeting joinability for Google Meet/Teams/Zoom where possible (e.g., require hosts to admit guests / disable anonymous joins) to reduce the impact of leaked conference IDs due to this leak or any future leaks.
- Engage tl;dv for a security statement (scope, logs, and remediation status) and require confirmation of tenant isolation controls before continued use.
Read more at Cybersecurity Reddit, Dark Reading, Talkback.sh
Red Hat launches ‘asago’ open-source project to turn AI governance policies into deployable controls
Red Hat announced asago, an open-source project designed to automate the translation of AI governance policies into operational safeguards and deployment configurations that ship with AI systems. The project aims to bridge the handoffs between compliance, data science, and platform teams by mapping requirements to common frameworks, generating risk-based tests and guardrails, and preserving an audit trail from each running control back to the underlying policy clause.
Key Details
- Asago is structured as a four-stage workflow: interpret policies, run use-case-specific safety tests, recommend mitigations/guardrails with rationale, then output deployment-ready configurations.
- It plans to map policy requirements to NIST AI RMF, OWASP Top 10 for LLM Applications, and the EU AI Act, using the IBM AI Risk Atlas for the mapping work.
- The project is intended to emit Kubernetes-, Terraform-, and Ansible-oriented artifacts for hybrid cloud and Kubernetes environments.
- Red Hat positions asago as a way to replace manual policy interpretation and custom scripting that can slow deployments and introduce errors as requirements move across teams.
- Asago is being developed with participants including Red Hat, IBM Research, Microsoft, Nvidia, MIT Lincoln Laboratory, and the Alan Turing Institute, and will be released under Apache License 2.0 (currently in project formation).
Next Steps
- If you’re evaluating AI governance automation, review the asago GitHub repo and governance info at http://asago.ai/ to assess fit for your policy-to-control workflow and Kubernetes/hybrid-cloud stack.
Read more at SiliconAngle
Connective Chrome extension origin-check bypass let arbitrary sites read Belgian eID data, trigger signatures, and reach Windows RCE via native host
A reported flaw in the Connective signing Chrome extension allowed any web page (including malicious ad iframes) to bypass origin validation and directly drive Belgian eID smart-card operations. In demos, this enabled silent identity/certificate reads, government-service account takeover by prompting once for a PIN and then signing silently, and Windows code execution via the extension’s native messaging host.
Key Details
- The Chrome extension was described as the only effective trust boundary; the native host, PKCS#11 middleware, PC/SC stack, and the card behave like a transparent pipe once the origin check is bypassed.
- Silent card reading worked without a PIN because Belgian eID identity data is not PIN-protected, exposing name, birth details, nationality, National Register Number, address, photo, and on-card certificates when the card is inserted.
- The account-takeover demo used an attacker-controlled ad iframe to drive eID authentication to a Belgian government service (certif.iamfas.belgium.be), requiring only a single PIN dialog with attacker-controlled text and then continuing with later signatures silently.
- The Windows RCE path was shown via the native host calling LoadLibraryA() on a web-controlled JSON field (“library”) with no validation, enabling arbitrary DLL loading in the host process as the current user.
- Stated deployment scope included government services, 8 of Belgium’s 10 largest banks, and the itsme identity platform (7.5M+ users), with impact framed as ~11.5 million Belgian citizens potentially exposed.
Read more at GitHub, chromewebstore.google.com, Talkback.sh, Cybersecurity Reddit
Subscribe
Subscribe to receive this weekly cybersecurity news summary to your inbox every Monday.
