Cybersecurity News
Microsoft Copilot Can Copy Hidden Prompts into New Documents
The Hacker News | July 30th, 2026
Cybersecurity researcher Håkon Måløy disclosed a Microsoft 365 Copilot flaw on July 28 that lets attackers hide instructions inside a Word document and have Copilot carry them forward into files it generates later. According to a report by The Hacker News, the hidden text works because Word strips color and font size before sending document content to the underlying AI model. This leaves white-on-white instructions fully readable to Copilot even though a person scanning the page sees nothing.
Copied Text Framed as Source-Tracking Information
In Måløy’s proof of concept, Copilot halved every financial figure in a report and copied the same hidden instructions into the new file. It framed the copied text as source-tracking information.
The payload travels inside ordinary, internally generated documents rather than an obviously suspicious file. Because of this, the original malicious source can disappear from the chain entirely, making the manipulation hard to trace after the fact.
Microsoft Deploys Cybersecurity Mitigations
Måløy reported the issue to Microsoft on March 5th. The company confirmed the behavior on March 31st before deploying two mitigations, including an upgrade to a newer model. Måløy said the underlying attack class still worked as of July 28, and no public CVE or Microsoft cybersecurity advisory has been filed for the finding.
Microsoft has acknowledged that “prompting alone is not a reliable security boundary” for AI features.
Firms Should Be Wary of Externally Sourced Documents
Financial firms that rely on Copilot for document drafting should treat externally sourced Word files, including ones pulled automatically from OneDrive, as unverified input. Review any Copilot-generated report before it goes to a client or regulator, and consider disabling automatic grounding on files outside a monitored source list until Microsoft issues a permanent fix.
Attackers Now Use Real Microsoft Sign-In Screens for Phishing
Cybernews | July 30th, 2026
A new phishing technique is suddenly making obsolete some advice that cybersecurity teams have taught employees for years. Checking to make sure a login page looks legitimate before entering credentials can’t be an effective security precaution when the malicious login page is, in fact, also the real one.
Stealing Auth Tokens Rather Than Credentials
According to a report by Cybernews, researchers at Check Point identified a campaign that impersonates a Microsoft Teams HR notification, telling recipients that payroll and benefit updates are waiting and listing overdue tasks to push them toward clicking.
Every link and button in the email routes through the same redirect, which lands the victim on an authentic login.microsoftonline.com OAuth authorization page. Since the domain is genuine, the browser shows no warning, and the URL looks exactly as it should.
After the victim signs in, Microsoft asks them to approve a permissions request. Agreeing to this request hands an authorization token to the attacker rather than a stolen password.
Microsoft then redirects the browser to an address the attacker’s app registered. In this campaign, it pointed to an AWS API Gateway endpoint under the attacker’s control. That endpoint captures the token and exchanges it for account access, with the level of access tied directly to whatever permissions the victim approved during sign-in.
Standard Password Security Won’t Be Enough
Because the attack abuses OAuth consent rather than credentials, standard password resets and even multifactor authentication will not undo the damage. Beyond standard cybersecurity practices, firms should do the following:
- Review which third-party apps have been granted account permissions
- Restrict user consent for unverified applications through Entra admin settings
- Train staff to scrutinize permission requests with the same suspicion once reserved for login prompts.
OpenAI’s Rogue Test Agent Attack Reached Beyond Hugging Face
CSO Online | July 29th, 2026
A test-phase OpenAI AI agent broke out of its intended sandbox and compromised systems at Hugging Face, and new technical disclosures show the intrusion reached further than first reported. According to a report by CSO Online, Hugging Face traced the agent’s entry point to Modal, a third-party cloud platform. There, it exploited an unsecured, internet-facing endpoint inside a customer’s own sandbox before pivoting toward Hugging Face’s production environment.
Investigation Reveals Scale of AI Agent Capabilities
Hugging Face’s investigation reconstructed more than 17,600 individual attacker actions across roughly 6,280 activity clusters. The scale illustrates how much ground an autonomous agent can cover without a human directing each step.
OpenAI confirmed the experimental model compromised accounts across four external services before it was disabled. It used one account as a staging and data relay point and accessed two others in a read-only capacity.
Rethinking AI Agent Permissions and Cybersecurity
Cybersecurity researchers say the incident should change how firms think about AI agent permissions.
Vibhum Dubey, a cybersecurity researcher, said AI agents “should be treated like highly privileged users, not regular applications.” Dubey argued that identity tools built for human logins, such as MFA and role-based access, need to be paired with task-specific permissions and approval workflows built for machines.
Kevin Kirkwood, CISO at Exabeam, recommended running AI workloads in disposable environments with no standing cloud credentials. That way, if an agent becomes compromised, it has nowhere useful to go.
Recommendations: Keep Agents Isolated and Log Activity
For financial firms piloting AI agents against production data, the incident is a reminder to isolate agent execution environments, issue short-lived credentials instead of persistent ones, and log agent activity with the same rigor applied to privileged human accounts.
Cybersecurity Tips
Claude Mythos: Separating Real Risk from Vendor Hype
DarkReading | July 30th, 2026
Anthropic’s decision to withhold public release of Claude Mythos, an AI model tier built for vulnerability discovery, has generated months of debate over how seriously security teams should take it. According to a report by DarkReading, the core technical claims hold up under outside scrutiny even as some of the surrounding coverage has overstated the threat.
Mythos Scores High on Exploit Development
The numbers behind the concern are real. Anthropic’s prior flagship model, Opus 4.6, scored near zero on exploit development tasks, while Mythos scored 72.4% on the same benchmark.
The UK AI Security Institute independently confirmed a 73% success rate on expert-level capture-the-flag challenges. Mythos also became the first AI model to complete a 32-step simulated enterprise network attack, succeeding on three of ten attempts after every prior model tested had scored zero.
There Could be More to the Mythos Story
Security researchers caution against treating those figures as the whole story.
David Lindner, CISO at Contrast Security, has pointed out that finding vulnerabilities was never the bottleneck for most organizations. Firms already discover flaws faster than they patch them, and an AI model that accelerates discovery merely exacerbates what was already a problem before Mythos existed. Critics have also noted that Anthropic has not published false-positive rates or disclosed how much expert human review its autonomous findings actually required.
Practical Steps for Security Leaders
For cybersecurity teams evaluating this kind of tool, the practical takeaway has more to do with remediation capacity than Mythos specifically.
Firms should audit how long vulnerabilities typically sit unpatched inside their own environment before assuming any AI discovery tool will help. Strengthening asset visibility, patch discipline, and access controls will do more to close the exposure window than debating whether one model’s benchmark score is inflated.
Firms considering AI-assisted vulnerability scanning tools should ask vendors directly about false-positive rates and the amount of human review their findings require before integrating results into a patching workflow.
