❌

Normal view

Received β€” 16 July 2026 ⏭ News

β€œAI Normal Tech” vs β€œAGI by Tuesday”: Security Advice That Survives Either Future

βœ‡Anton on Security
By: Anton Chuvakin
16 July 2026 at 01:12

If you look at social media debates about AI, two extreme patterns emerge. Studying extreme patterns is very useful because understanding boundary conditions helps you understand the whole phenomenonβ€Šβ€”β€Šin this case of security in AI adoption (recent extreme example). You can also do all sorts of fun scenario planning withΒ this.

Predictably, security leaders have caught the same fever, and even some technologists did. Let’s catalog them likeΒ this:

  • Camp 1 (The Meh Camp): This camp spans a spectrumβ€Šβ€”β€Šfrom the hard cynics (β€œit’s autocomplete with a marketing budget,” LLMs are stochastic parrots, there is no β€˜intelligence’ anywhere in the building) to the more measured β€œAI as normal technology” crowd, who concede the tech is real, but expect it to diffuse slowly and messily over decades. What unites them: no discontinuous jump, no paradigm rupture, no exponents, no robot overlords. And yes, β€œthe parrot wing” of this camp is alive and well in some very senior securityΒ circles.
  • Camp 2 (The Deep Believers): AGI is coming by β€œnext Tuesdayβ€β€Šβ€”β€Šor 2027 at the absolute latest. This camp also spans a spectrum, from the β€œdoomer” accelerationists who foresee inevitable, systemic collapse to the optimistic futurists anticipating a complete, rapid upheaval of the global security landscape. Some hold this timeline with religious fervor while being unable to define β€œintelligence” if their bonus depended on it. What unites them is the conviction that we are facing an immediate, discontinuous, exponential leap in capability that will render all traditional defensive strategies obsolete overnight. And yes, there are influential security leaders who lean heavily into thisΒ camp.

Here is the fun part and the point of this blog: you don’t need to know who’s right. In fact, betting your security program on either camp being right is the actual mistake I want to pointΒ out.

Maybe the Parrot camp is right. Maybe the AGI-doomers are spot on. Or maybe the truth is somewhere in the swampy middle. If you find yourself unable to justify a security investment without first winning a philosophy-of-mind debate, you are doing itΒ wrong.

But let’s instead ponder what works in β€œeither / neither / both” cases.

What security advice remains correct today and for the medium term without relying on either camp beingΒ right?

One structural note before we start: every section below runs the same play. What the β€œparrot future” does to you. What the β€œAGI Tuesday” future does to you. What you do about bothβ€Šβ€”β€Šwith one control. Watch how many times the answer converges.

That convergence is my argument (with help from Gemini and ClaudeΒ Fable).

Universal Security Controls for BothΒ Futures

If you’re Camp 1β€Šβ€”β€Šwhether the parrot wing or the β€œnormal technology” wingβ€Šβ€”β€Šyou believe AI is an incremental extension of β€œclassic” ML: it accelerates existing security processes without any dramatic paradigm shift. But even then, you concede it speeds things upβ€Šβ€”β€Šincluding for attackers, who now discover vulnerabilities and misconfigurations faster and phish with impeccable grammar (nobody, not even the β€œparrotiest” parrot will argue with this one!). If you’re Camp 2, you may be surprised to see that these same controls apply, just with the volume knob turned to 11 atΒ times.

1. Configuration Hygiene

Boring? Yes. Optional? Definitely not. Cloud misconfigurations and weak baselines remain the #1 way attackers walk in through the front doorβ€Šβ€”β€Šno AGI required, thank you veryΒ much.

  • Parrot future: attackers use AI to find your misconfigurations faster. The parrot doesn’t need to be smart; your S3 bucket isΒ public.
  • AGI future: the β€œsuperintelligent” attacker also starts with your public S3 bucket, because why use an AI-crafted zero-day when the door isΒ open?

The universal control: treat configuration hygiene as tier-1 defense, with continuous (not quarterly!) posture validation. Hygiene is the rare control that is equally valuable whether AI is a mildly better β€œgrep” or an existential threat (Claude came up with this metaphor, thanks buddy, it almost rhymes). If your AI security roadmap has β€œagentic red teaming” on it but not β€œclose the open buckets,” you are accessorizing a house with no doors. See good argumentΒ here.

2. Threat Detection & Security Monitoring

You do recall I had a title β€œChief Logging Evangelist” a few years back (β€œA few, Anton”? Who are you kidding?” … Anyhow…) Your SOC or D&R team or whatever you call it still needs to log, sense, detect, investigate, etc.

  • Parrot future: your normal systems face automated, AI-accelerated attacksβ€Šβ€”β€Šsame TTPs, faster tempo, and phishing that finally spells β€œinvoice” correctly. Your triage queue was built for human-speed adversaries; it is about to meet an assemblyΒ line.
  • AGI future: the AI systems themselves become the thing to watchβ€Šβ€”β€Šinputs, outputs, tool calls, and internal telemetryβ€Šβ€”β€Šbecause prompt injection, abuse, and quiet exfiltration through an agent leave traces nowhere in your current detection content.

The universal control: log and detect. Your classic estate under machine-accelerated attack, and your AI stack as a first-class telemetry source with its own detections (devil here is in the details, as usual). I admit this smells like an β€œEasier Said Than Done” competition entry with some chance of getting a 3rd prize. But the fact remains: good logging helps you in eitherΒ case.

3. Accelerated Vulnerability Management

Vulnerability managementβ€Šβ€”β€Šdealing with security-relevant flaws in vendor software and your own code and open source codeβ€Šβ€”β€Šmust run on a faster clock in 2026. The clock disagreement between the camps is about how much faster, not whether. Think 30%+, 2x, 10x or β€œwe are all gonna die”xΒ :-)

  • Parrot future: AI compresses the exploit timeline the boring wayβ€Šβ€”β€Šfaster recon, faster PoC-to-prod exploit code, β€œcommodity” attackers punching above their weight class. Your 30-day patch SLA quietly became a 30-day β€œwe have a front door open, locks what locks” period.
  • AGI future: β€œPatching is dead! The machines will find zero-days continuously!” Fine. Even granting the premise, the conclusion isn’t β€œgive upβ€β€Šβ€”β€Šit’s that mitigation and rewriting becomes the wholeΒ game.

The universal control: vulnerability management inclusive of mitigation planning (segmentation, β€œvirtual” patching, compensating controls, config weakness scanning, etc) becomes more critical under both futures, not less. Most companies cannot break their β€œpatch sound barrier”, AI or no AI. When you can’t fix the flaw, you’d better be able to contain the blast radius. Note the irony: the AGI camp’s own argument makes the boring VM discipline more important. Funny how thatΒ works.

4. Data Security & Sensitive Data Discovery

Both camps should care deeply about knowing where their sensitive data lives, but they lose sleep over different nightmares:

  • Parrot future: the risk is leakage and compliance. Employees will lovingly paste source code, PHI, and PII into consumer chatbots to β€œpolish an email.” Regulators do not accept β€œthe parrot ate my data” as a defense. Am I overdoing the β€œparrot thing” here?
  • AGI future: the risk shifts to poisoning and exploitation. An agentic system with access to poorly governed data repositories plus one well-crafted prompt injection equals an AI that cheerfully exfiltrates things it should never haveΒ touched.

The universal control: build a real-time, accurate inventory of your sensitive dataβ€Šβ€”β€Šand yes, AI-automated sensitive data discovery and mapping is finally real (while in 2016, it largely was not, for most organizations). The uncomfortable truth: most organizations spent two decades not doing data security because it was hard and nobody made them. AI just made β€œwe don’t know where our data is” much more painful, whether you are β€œcamp parrot” or β€œcamp AGI.” Heard this advice before? Yes, you did. So? Did you actually try implementing it? Well, now you need to, parrots orΒ not.

5. Shadow AI Governance & Sanctioned Alternatives

Banning public AI tools is the ultimate security theaterβ€Šβ€”β€Šright up there with confiscating USB sticks in 2009 or banning Internet connectivity in 1998 (β€œbut why would you need the internet for work?!”). It doesn’t stop usage; it just moves it to personal phones and personal accounts, where you can’t see it, log it, or ever get the dataΒ back.

  • Parrot future: employees casually feed proprietary code and PII into consumer LLMs, generating incidents and triggering your lawyercats unnecessarily.
  • AGI future: well-meaning developers hand API keys and internal data access to unmonitored shadow agents and creating a sprawling, autonomous attack surface that nobody owns. WhatΒ fun!

The universal control: stop playing firewall whack-a-mole. Get visibility (CASB and DLP are still a thing, yes, really!), then remove the excuse: offer a sanctioned enterprise AI tool with real contractual data protections. People take shortcuts when the official path is a dirt road. Pave it. And if your ban is still in place in 2026, understand that you don’t have a policyβ€Šβ€”β€Šyou have a shadow inventory problem you’ve chosen not toΒ measure.

6. Identity & Access forΒ Agents

Here’s the control nobody had on their 2016 bingo card: least privilege for machines that ask nicely. We barely handled NHI (no, we never did, IRL) and now we have β€œagent identity” with a pillow fight ongoing on β€œis agent more like an employee or more like a workload”…

  • Parrot future: AI tools and integrations quietly accumulate OAuth grants, service accounts, and long-lived API keysβ€Šβ€”β€Šclassic non-human identity sprawl, now with extra steps. Regular NHI problem left unsolved would kill you slowly, the agentic one will workΒ faster.
  • AGI future: autonomous agents holding broad credentials become the single most attractive target in your enterprise. Compromise the agent, inherit its permissionsβ€Šβ€”β€Šand its work ethic. Tricking an agent to do β€œa rogue action” is becoming more popular everyΒ day…

The universal control: treat every agent, and integration as an identity with a lifecycle (!). Scope it, time-limit it, log it, and review it. Your agents currently have more access than your interns and sometimes less judgment. Fix at least one of thoseΒ ;-)

7. Environmental Reality Testing vs. Marketing Benchmarks

Model capability benchmarks are largely a mirage if they do not match your realities. A high score on a vendor slide means precisely nothing about your production environment, if you are notΒ them.

  • Parrot future: blind trust in claimed accuracy yields silent failures, hallucinations in critical workflows, and surprise data leakageβ€Šβ€”β€Šthe parrot passed the exam and still can’t do the job. I am not adding β€œit will peck you to death”, this is where I draw theΒ line…
  • AGI future: deploying an agentic system for consequential autonomous tasks without validation invites systemic, unpredictable behaviorβ€Šβ€”β€Šan advanced agent breaking things faster than you can file the postmortem.

The universal control: ignore the brochure. Run internal, multi-run reliability testing and AI red-teaming in your environment with your data before any AI system earns operational duties. Trust is earned in your environment, not on the vendor’s leaderboard. Here’s the provocative version: if your AI procurement process accepts benchmark scores as evidence, your procurement process is part of your attackΒ surface.

Moving Beyond theΒ Debate

And, yes, we could keep adding entries (asset management, IR playbook updates for AI incidents; the list of unglamorous-but-necessary goes on). But you’ve seen the pattern ten times now, so let’s nameΒ it.

The two camps diverge violently on timelines and on whether a discontinuous β€œAGI jump” is coming at allβ€Šβ€”β€Šyet they converge on the near-term necessity of architectural control, every single time. Autonomous agents, supply-chain exposure, machine-speed offense: both worldviews agree these risks are real, present, and demand actionΒ today.

When two groups who agree on nothing agree on your homework, the homework is probably real. If I hear one more CISO tell me they are β€œwaiting for the dust to settle on AI” before building a security strategy, I’m going to start charging for therapy. The dust isn’t settling. It’s just turning into more data you aren’tΒ logging.

So the next time someone tells you they can’t build an AI security strategy until the AGI debate settlesβ€Šβ€”β€Šsmile, nod, and go patch something. The philosophers will still be arguing next Tuesday. Your attackers won’t wait thatΒ long.

Summary

  • The dichotomy: security leaders split into the β€œnormal technology” camp (from stochastic-parrot cynics to slow-diffusion β€œpragmatists”) and the β€œAGI by next Tuesday” believers (and of course less extreme middleΒ too)
  • The core thesis: we do not need to settle the philosophical debate. Many of the same fundamental, no-regret controls apply regardless of which future arrives, and the camps’ convergence on near-term controls is itself the strongest evidence those controlsΒ matter.
  • The no-regret controls:
  • Treat configuration hygiene as tier-1 defenseβ€Šβ€”β€Šboth futures start at your public S3Β bucket.
  • Monitor both your normal systems under AI attack and the telemetry of your AI systems themselves.
  • Accelerate vulnerability management loops, with mitigation planning for the flaws you can’tΒ patch
  • Prioritize sensitive data discoveryβ€Šβ€”β€Šagainst leakage (low end) and poisoning/exploitation (highΒ end).
  • Replace blanket bans with sanctioned enterprise AI plus visibility.
  • Govern non-human identities: least privilege, lifecycle, and logging for every agent and integration.
  • Re-engineer threat models and containment for machine-speed intrusions.
  • Ignore synthetic vendor benchmarks; mandate local adversarial red-teaming before operational trust.

β€œAI Normal Tech” vs β€œAGI by Tuesday”: Security Advice That Survives Either Future was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

Received β€” 11 July 2026 ⏭ News

VU#564823: GNU Wget enables SSRF via unvalidated FTP PASV IPs

βœ‡CERT Recently Published Vulnerability Notes
By: CERT
10 July 2026 at 20:19

Overview

GNU Wget, versions 1.25.0 and earlier, contains a server-side request forgery (SSRF) vulnerability in its implementation of FTP passive mode. Because Wget does not properly validate IP addresses obtained from PASV responses, an attacker-controlled FTP endpoint can redirect the client’s connection to arbitrary IPs, potentially exposing internal network host and service responses. This vulnerability has been remediated in a recent update by GNU; see the Solutions section below for resolution guidance.

Description

GNU Wget is a widely used command-line utility for retrieving content over HTTP, HTTPS, and FTP. When operating over FTP in passive mode, Wget relies on the server’s PASV response to determine which IP address and port to use for the data connection.

CVE-2026-15146 GNU Wget does not validate the IP address provided by an FTP PASV response while operating in FTP passive mode. A malicious FTP server, or an HTTP server that redirects to an FTP URL, can exploit this behavior to redirect Wget’s data connection to an arbitrary IP address and port. This allows an attacker to forge server-side requests (SSRF) from the machine running Wget, potentially accessing localhost services or internal network resources.

This issue belongs to a known class of FTP PASV vulnerabilities such as CVE-2021-40491, which was previously remediated in GNU Inetutils.

Impact

A remote attacker controlling or influencing an FTP endpoint can induce Wget to establish connections to otherwise inaccessible internal network addresses. This may allow the attacker to retrieve service banners, access internal HTTP endpoints, or exfiltrate data from internal systems reachable by the victim host. Applications that embed Wget for automated retrieval are particularly susceptible, because the vulnerability may be triggered automatically through redirected requests and untrusted user-supplied URLs.

Solution

GNU Wget has remediated this issue in the 07/05/2026 commit 4f85853f641863d5915786a8413e1a213726a62b. Users are advised to update their version according to vendor guidance.

Acknowledgements

Thanks to Jeremy Brown for researching and reporting this vulnerability. This document was written by Molly Jaconski.

Vendor Information

One or more vendors are listed for this advisory. Please reference the full report for more information.

Other Information

CVE IDs: CVE-2026-15146
Date Public: 2026-07-10
Date First Published: 2026-07-10
Date Last Updated: 2026-07-10 18:19 UTC
Document Revision: 1

VU#152953: PayRange Android app version 7.0.7 contains multiple vulnerabilities

βœ‡CERT Recently Published Vulnerability Notes
By: CERT
9 July 2026 at 19:03

Overview

PayRange is a mobile payment app that allows users to pay for vending machines, laundromats, and other unattended machines using a smartphone with Bluetooth. Two vulnerabilities were discovered in version 7.0.7 of the PayRange app that is available in the Google Play store.

Description

A vulnerability (CVE-2026-13462) exists in the PayRange Android app that causes invalid SSL certificates to be accepted in application WebViews. A second vulnerability (CVE-2026-13461) exists that allows the injection of JavaScript, which can be used to escape the WebView sandbox and perform a number of dangerous actions on the user's device. These vulnerabilities were discovered in version 7.0.7 of the PayRange app.

The PayRange app bypasses Android's SSL trust chain and accepts certificates that match any of the following rules (including self-signed certificates):

  • Common Name ends with "payrange.com"
  • Common Name contains "stripe.com"
  • Common Name contains "fetlifestatus.com" AND any of these conditions are true:
  • Issuer Common Name is "R10"
  • Issuer Common Name is "R3"
  • Issuer Common Name contains "Network Solutions"

The attack vector is an on-path interception. If an attacker can direct traffic intended for a legitimate server to a device they control, they can negotiate a TLS connection with the user's device using any trusted certificate that matches the rule set. They are then able to inject content into the WebView and harvest credentials, issue malicious requests and read data entered by the user, including exchanges with the PayRange and Stripe servers.

Impact

An attacker may be able to intercept any information they can convince the user to send through the app. If the user is a machine operator, the injected JavaScript code can also connect to PayRange hardware and issue commands with the full permissions of the operator.

Solution

Unfortunately, we were unable to reach the vendor to coordinate this vulnerability. Apply the latest software updates provided by your hardware or software vendor as they become available.

Acknowledgements

Thanks to Tahi Wilton Geary for reporting this vulnerability. This document was written by Bob Kemerer.

Vendor Information

One or more vendors are listed for this advisory. Please reference the full report for more information.

Other Information

CVE IDs: CVE-2026-13462 CVE-2026-13461
Date Public: 2026-07-09
Date First Published: 2026-07-09
Date Last Updated: 2026-07-09 17:14 UTC
Document Revision: 2

VU#734812: Xerte Online Toolkit contains an authentication bypass that allows for RCE

βœ‡CERT Recently Published Vulnerability Notes
By: CERT
9 July 2026 at 14:37

Overview

Two vulnerabilities have been discovered in Xerte Online Toolkits, an open-source e-learning authoring toolsuite intended for the creation of learning materials within a web browser. CVE-2026-14261 tracks the persistence of the /setup/ directory after installation, which allows an unauthenticated attacker to reconfigure the application to point to a remote database they control in order to gain administrative access. CVE-2026-12116 tracks an editable antivirus binary path that can be redirected to a PHP interpreter, causing uploaded files to be executed as PHP code and resulting in remote code execution (RCE). Version v3.15.5 or v3.14.6 of Xerte Online Toolkits fixes these vulnerabilities.

Description

Xerte Online Toolkits is a suite of a free, open-source e-learning authoring tools that allows users to make educational materials directly in-browser. The toolset is installed from multiple packages, and creates a setup folder that persists after installation.

CVE-2026-14261
A vulnerability in Xerte Online Toolkits allows for authentication bypass and remote code execution via reinstallation through the /setup/ folder, enabling attackers to reinstall the service to a remote database they control.

CVE-2026-12116
A vulnerability in Xerte Online Toolkits allows for RCE through the antivirus binary path in the tools server settings. The antivirus binary runs on all uploaded files, but the path to the binary can be modified using the configuration menu. An attacker can achieve remote code execution by redirecting the path to a PHP interpreter, causing any uploaded PHP scripts to be executed.

During installation, Xerte creates a /setup/ folder to configure database connection settings. This folder persists post-installation without access controls or automatic cleanup, and /setup/index.php does not verify whether installation has completed. An attacker can revisit /setup/ and reconfigure the application to point to a remote database, thereby gaining administrative access.

After gaining admin privileges, an attacker can abuse CVE-2026-12116 by editing the antivirus binary path to point to a PHP interpreter. This causes any new uploaded files to be passed to the PHP runtime through website_code/php/import/fileupload.php, bypassing file extension checks and resulting in remote code execution.

Impact

Successful exploitation can allow full remote code execution on the affected server. This enables attackers to establish persistent access, exfiltrate data, or launch supply chain attacks by injecting malicious content into educational materials distributed by the platform.

Solution

These issues have been addressed in two commits:
- 8fec660 removes /setup/ automatically after installation/upgrade and blocks reuse.
- 8ef2062 moves sensitive configuration files, including the antivirus binary path, to server-side locations.

Users should take the following steps immediately:
1. Manually remove the initial installation /setup/ folder from installations.
2. Upgrade to Xerte v3.15.5 or v3.14.6 and run upgrade.php, which enforces automatic /setup/ removal and includes security hardening. If removal fails, the updated code still prevents exploitation.
This blog post: https://www.xerte.org.uk/index.php/en/news/blog/80-news/364-xerte-3-14-and-3-15-important-security-update contains more information and contact data for Xerte.

Acknowledgements

Thanks to the reporter, George Filippov from the Vexel Foundation. This document was written by Christopher Cullen.

Vendor Information

One or more vendors are listed for this advisory. Please reference the full report for more information.

Other Information

CVE IDs: CVE-2026-12116 CVE-2026-14261
Date Public: 2026-07-09
Date First Published: 2026-07-09
Date Last Updated: 2026-07-09 12:37 UTC
Document Revision: 1

VU#849433: Adalo Database API Enables Cross-App User Data Extraction via Over-Fetching and Missing Authorization Controls

βœ‡CERT Recently Published Vulnerability Notes
By: CERT
8 July 2026 at 16:03

Overview

Adalo’s no‑code application platform exposes complete user records through its database API for all applications built on both V1 and V2. Due to a platform-level flaw, authenticated users can retrieve full user data belonging to any Adalo application, regardless of configuration. This issue affects more than one million applications and placing developers and their end users at risk of data exposure that they cannot prevent or remediate.

Description

Adalo is a Software-as-a-Service (SaaS) provider for building no-code applications. In theory, each application or tenant (customer) is logically isolated with separate databases, users, and configurations.

CVE-2026-10706 Unrestricted Disclosure of Full User Records
The Adalo database API contains a flaw which allows the backend to return complete user records for every list component request, regardless of which fields the component is configured to display. The database does not enforce ownership‑aware, server‑side authorization checks, allowing authenticated users of any Adalo application to query database and table identifiers belonging to other applications and retrieve full records, including fields not requested. This issue is amplified by the permissive CORS policy, plaintext storage of all text files and evidence suggests that deleted records may remain accessible.

CVE-2026-10708 Exposure and Reuse of Long-Lived JWT Tokens
The JWT tokens are visible in client‑side requests and remain valid for approximately twenty days. Once copied, they can be reused from any external website or script to query the database API directly. Because the platform allows requests from any origin, attackers can repeatedly query the API and extract large volumes of user data without interacting with the application itself. The combination of exposed tokens, permissive CORS behavior, and large response limits enables persistent, automated harvesting of entire user databases using only a single token obtained from any visitor session.

Impact

These vulnerabilities affect all Adalo applications across both V1 and V2. Because they occur at the platform level, the entire population of Adalo‑built applications is impacted.

Exposure of Sensitive Information to an Unauthorized attacker (CVE-2026-10706) Attackers may extract full user records and correlate user behavior across multiple applications via dbId enumeration. The platform does not implement data minimization, privacy by design, or implement appropriate technical safeguards, allowing sensitive information to be exposed to unauthorized parties.

Insufficiently Protected Credentials (CVE-2026-10708) This vulnerability enables large‑scale data harvesting without requiring app‑specific secrets. A single request to a minimal leaderboard component may return user records containing emails, UUIDs, and custom fields. The combination of wildcard CORS behavior, long‑lived twenty‑day JWTs, and the absence of token revocation allows attackers to gather sensitive personal information from any Adalo application.

Solution

Adalo contains an access control weakness that may allow unauthorized users to bypass application boundaries under certain conditions. Adalo has acknowledged the issue, however, no patch is currently available. Customers and tenants should assume data in Adalo collections may be exposed, and avoid storing sensitive information there until a patch is deployed. Users should remain aware of increased phishing and identity theft risks and monitor their accounts for suspicious activity.

Acknowledgements

Thanks to the reporter Saud Darwish. This document was written by Laurie Tyzenhaus.

Vendor Information

One or more vendors are listed for this advisory. Please reference the full report for more information.

Other Information

CVE IDs: CVE-2026-10706 CVE-2026-10708
Date Public: 2026-07-08
Date First Published: 2026-07-08
Date Last Updated: 2026-07-08 14:03 UTC
Document Revision: 1

VU#213560: Tenda firmware (multiple versions) contains hidden authentication backdoor

βœ‡CERT Recently Published Vulnerability Notes
By: CERT
6 July 2026 at 21:22

Overview

Several versions of Tenda firmware contain an undocumented authentication backdoor that grants administrative access to the devices' web management interfaces. An attacker can expoit this vulnerability, tracked as CVE-2026-11405, to bypass the password verification process and obtain full administrative control without valid credentials.

Affected Versions:
* US_FH1201V1.0BR_V1.2.0.14(408)_EN_TD
* US_W15EV1.0br_V15.11.0.5(1068_1567_841)_EN_TDE
* US_AC10V1.0re_V15.03.06.46_multi_TDE01
* US_AC5V1.0RTL_V15.03.06.48_multi_TDE01
* US_AC6V2.0RTL_V15.03.06.51_multi_T

Description

Tenda is a supplier of home and business network devices such as routers, switches, wireless access points, and video surveillance equipment. Most of these devices include web-based interfaces that allow users to perform configuration and management operations, which are protected by username/password authentication to prevent unauthorized modifications.

The web server binary /bin/httpd contains an undocumented backdoor authentication mechanism in the login() function. Initially, the function follows a normal authentication path using MD5-based password verification. However, if authentication fails, the function invokes GetValue("sys.rzadmin.password") to retrieve an alternate password value from the device configuration. It then performs a direct strcmp() comparison in plaintext between the user-supplied password and the configuration-stored value. A successful match grants role=2 admin-level access and creates a valid session.

The associated username is not validated, so any provided username will succeed when paired with the backdoor password. This backdoor authentication mechanism is not documented or visible through any administrative interface.

Impact

Successful exploitation grants full administrative access to the device's web interface, regardless of the configured administrator account credentials. With administrative control, an attacker can reconfigure the device, alter network settings, and disable security features, enabling broader compromise of the local network.

Solution

Unfortunately, we were unable to reach the vendor to coordinate this vulnerability. Since a patch is unavailable, we can only offer mitigation strategies. The following workarounds can help mitigate this vulnerability's impact until a fixed version is released:

Disable remote management on your device
If your device supports remote web management, disable it. Disabling this feature prevents attackers on external networks from accessing your device’s administrative dashboard over the internet.

Restrict local network exposure
Changing the default LAN IP address may reduce opportunistic discovery by automated scanners that target known default IP ranges. Note that this measure does not prevent deliberate or targeted network scanning.

Acknowledgements

Thanks to the reporter who wishes to remain anonymous. This document was written by Bob Kemerer.

Vendor Information

One or more vendors are listed for this advisory. Please reference the full report for more information.

Other Information

CVE IDs: CVE-2026-11405
Date Public: 2026-07-06
Date First Published: 2026-07-06
Date Last Updated: 2026-07-06 19:22 UTC
Document Revision: 1

VU#828543: HP Deskjet 2800 Printer Series Webservers contain Missing Authorization Vulnerability

βœ‡CERT Recently Published Vulnerability Notes
By: CERT
6 July 2026 at 19:59

Overview

HP Printers in the Deskjet 2800 Series running firmware version <=TBP1CN2612AR contain a missing authorization vulnerability tracked as CVE-2026-13753. This vulnerability allows unauthenticated access to the printer's webserver API endpoints, exposing Wi-Fi credentials, management configuration details, and sensitive security data normally restricted to administrative users.

Description

Modern HP printers provide a web-based management interface for configuring content such as Wi-Fi Direct settings, SNMP management access, and device security options. When accessed normally through the browser interface, these pages explicitly require administrator credentials before sensitive information is displayed. This information is protected because, for example, Wi-Fi Direct controls the printer's direct wireless connectivity, and SNMP configuration settings can reveal detailed information about the device's monitoring and management controls.

In affected firmware versions, the authorization requirement can be bypassed by sending direct, unauthenticated GET requests to multiple backend API endpoints. The affected endpoints return administrative configuration data without validating session state or authentication, including the Wi-Fi Direct SSID and plaintext passphrase, unique printer serial numbers and service IDs, and details about the device's administrative password state. This information is freely disclosed even though the corresponding web interface pages correctly enforce authentication, indicating an authorization flaw in the API layer.

Impact

A remote attacker with network access to the printer can bypass the web interface's authentication requirements and retrieve sensitive configuration data directly from backend APIs. Exposed information includes Wi-Fi Direct credentials, SNMP configuration details, device identity information, cloud service registration metadata, and other information involving the device's administrative security state. An attacker could use this information to gain unauthorized wireless access, perform reconnaissance on network or cloud integrations, impersonate the device, or facilitate further compromise of the printing environment.

Solution

Unfortunately, we were unable to reach HP to coordinate this vulnerability, so a firmware patch is not yet available. To limit the risk of this vulnerability, users should restrict network access to the printer's web interface by placing the device on a trusted or isolated network segment, disable Wi‑Fi Direct if it is not required, and limit SNMP access to trusted systems or disable it entirely. Firewall or access-control list (ACL) rules should be used to prevent untrusted hosts from reaching the printer's management ports, and discovery or cloud service features that are not needed should be disabled.

Acknowledgements

Thanks to Nguyα»…n TiαΊΏn DΕ©ng for researching and reporting this vulnerability. This document was written by Molly Jaconski.

Vendor Information

One or more vendors are listed for this advisory. Please reference the full report for more information.

Other Information

CVE IDs: CVE-2026-13753
Date Public: 2026-07-06
Date First Published: 2026-07-06
Date Last Updated: 2026-07-06 18:01 UTC
Document Revision: 2

From Cloud to Chaos: Defining Shared Responsibility for AI Security

βœ‡Anton on Security
By: Anton Chuvakin
2 July 2026 at 19:26

For 15 years (!), many of us who have touched cloud security have struggled with the shared responsibility model for cloud security. As with many β€œcyber things,” the theory is simple. Multiple vendors, consulting firms, and industry bodies have published deceptively clear matrices that depict exactly who is doing what for cloud security.

Everyone likes to present trivial cases: for example, the cloud provider is entirely responsible for the physical security of the data center, while the client is responsible for the application they just built and deployed within that cloud provider’s IaaS. In reality, many of the edge cases continue to cause pain to a lot of organizations.

Ok, so none of this is fundamentally new. However, in recent years, similar and more complex - dare I say sinister?- questions have emerged: What does shared responsibility look like for AI security?

Those who haven’t studied this topic in depth might assume there is no difference. Yet, there are fascinating, critical differences between shared responsibility for AI security and traditional cloud security, along with older related challenges like the shared security of outsourcing (that predateΒ cloud).

Add AI with its probabilistic behaviors, untrusted user inputs, and nested vendor dependencies -and that finger-pointing cycle doesn’t just continue, it scales exponentially. When a customer-facing chatbot goes off the rails, the model provider blames your prompt engineering, the platform provider claims infrastructure isolation worked perfectly, and your internal application team swears it’s an upstream model limitation…

Put simply, what are the top 3 differences between shared responsibility for AI vs cloud? In myΒ opinion:

  1. A Broader Spectrum of Risk: The range of harms and risks we must consider is much wider. Shared responsibility for AI security frequently touches upon safety, privacy, ethical use, and the unique risk surfaces that emerge specifically in conversations aboutΒ AI.
  2. The Multi-Party Supply Chain: AI security is typically far more multi-party than traditional cloud security. For instance, one company builds the foundational model, another company fine-tunes it, a third party builds a Retrieval-Augmented Generation (RAG) architecture for you, and yet another party builds the consumer-facing application.
  3. Non-deterministic Behavior: Unlike traditional cloud infrastructure where secure configurations yield predictable, deterministic outcomes, AI systems are non-deterministic. Because outputs can vary significantly based on user inputs, customers bear increased responsibility for implementing robust guardrails, continuous monitoring, and input/output filtering.

Early attempts to create a logical foundation for AI shared security responsibility produced some answersβ€Šβ€”β€Šand more questions.

In light of this being a tricky problem, here I really want to focus on one thingβ€Šβ€”β€Ša post-incident scenario. While shared responsibility covers numerous use cases (and numerous sources of confusion…), let’s examine a fairly straightforward situation: I am an enterprise end-user company that uses (maybe builds, maybe tunes, etc) AI in some form, then something blows up (digitally, as this is not IoT/ICS security blog).Β So:

  • Who takes a loss vs who is toΒ blame?
  • Do I blame the model creator? The application developer? The model hosting platform? Or do I ultimately blameΒ myself?

If you recall, many early challenges with the cloud shared responsibility model began with customers trying to blame the provider, only to discover they were actually at fault in the end. We tried to change this dynamic by introducing a β€œshared fate” model. While that specific terminology has seemingly fallen out of favor lately, the underlying philosophy remains: providers can probably do more to make AI usage inherently secure.

I was recently involved with a CoSAI (Coalition for Secure AI) working group to develop a paper covering the shared responsibility framework for AI security. As others on the team humorously pointed out, my voice was one of the loudest calling for the paper to be kept simple, crisp, and highly usable. You can judge based on the final result whether we succeeded.

CoSAI matrix

We recently wrapped up and approved Version 1.0 of the CoSAI AI Shared Responsibility Framework (AI SRF) through the Coalition for Secure AI and OASIS Open. The core mission here wasn’t to build more abstract compliance theater, but to solve a practical, glaring operational pain point: Who actually owns what when an AI systemΒ fails?

Under the CoSAI framework, accountability traces down the stack with absoluteΒ clarity:

  • The AI Model Provider (L5) is accountable for the base model’s inherent susceptibility to prompt injection and must document those boundaries explicitly within the modelΒ card.
  • The Cloud/Platform Provider (L4) is accountable for the blast-radius containment, ensuring infrastructure-level tenant process isolation held firm during the exploitation.
  • The Application Developer (L3) is accountable for failing to enforce application-level guardrails, input filtering, and localized data access controls that allowed the chatbot to hit the PII repository in the firstΒ place.
  • The Deploying Organization (L1/L2) is accountable for the ultimate governance failure: they did not properly classify the data or restrict the chatbot’s system-level access boundaries before pushing itΒ live.
Layers

Also, the paper included a phased Implementation Playbook in the document to give security teams a somewhat specific pathΒ forward:

  1. Phase 1 (Days 1–30): Map your entire AI system inventory and cross-reference vendor contracts against these five layers to highlight immediate responsibility gaps.
  2. Phase 2 (Days 31–90): Establish a cross-layer governance committee and formally update vendor procurement contracts with clean, explicit accountability matrices.
  3. Phase 3 (12 Months): Run layer-specific tabletop simulations to stress-test your incident response playbooks before an actual threat actor tests them forΒ you.

Fun quotes:

  • β€œAmbiguous ownership is a growing liability for Al system deployments.” [A.C.β€Šβ€”β€Šfiled under β€˜no shit, Sherlock’]
  • β€œWithout explicitly assigned owners for detection, containment, and remediation, teams default to the finger-pointing cycle” [A.C.β€Šβ€”β€Šthis will get worse, then MUCH worse, then eventually better…]
  • β€œThe framework turns β€˜whose fault is this?’ into β€˜which layer’s controls failed, and who owns remediation for each?’” [A.C.β€Šβ€”β€Šthis is beautifully, I probably wrote thisΒ :-)]
  • β€œThere should be exactly one accountable party per component to prevent overlaps.” [A.C.β€Šβ€”β€Šideal world called, it wants its problem back! Real world picked up and said β€˜getΒ lost’]
  • β€œClear accountability eliminates finger-pointing during incidents” [A.C.β€Šβ€”β€Šclear evidence that Captain Obvious isΒ alive!]

More seriously, read theΒ paper!

In the end, I hope this work enlightens people on just how complex this problem truly is. This paper is definitely not a silver bullet that solves everything overnight; we have years of discussions and evolving challenges ahead of us down this path. However, I think this paper serves as an excellent first step. Please make sure to check out the resources listed at the end of the paper as well (a lot of gemsΒ there!)

Related blogs:

From Cloud to Chaos: Defining Shared Responsibility for AI Security was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

VU#639124: Multiple local privilege escalation vulnerabilities in Little Orbits GameFirst Anti-Cheat

βœ‡CERT Recently Published Vulnerability Notes
By: CERT
2 July 2026 at 16:34

Overview

The GamersFirst Anti-Cheat (GFAC) driver GFAC.sys contains multiple local privilege escalations and denial-of-service vulnerabilities stemming from insecure handling of user-controlled input through a minifilter communication port. A local attacker can abuse these flaws to perform arbitrary kernel memory writes, obtain privilege escalation to SYSTEM, or trigger a system crash.

Description

GFAC is a proprietary anti-cheat software developed by video game publisher Little Orbit. GFAC includes a kernel-mode driver, GFAC_Sys_x64.sys, that exposes privileged functionality to user-mode applications through a minifilter communication port. Although these low-level interfaces are necessary for the software's operation, vulnerabilities can arise if user-mode access is not properly restricted and validated.

CVE-2026-12166 GFAC_Sys_x64.sys contains a NULL pointer dereference condition in its initialization and request handling logic. A local attacker can trigger the vulnerable code path, causing the driver to read or write to a memory address assigned as NULL. Successful exploitation results in a system crash (β€œblue screen of death”).

CVE-2026-12167 The minifilter communication port that GFAC_Sys_x64.sys exposes does not enforce sufficiently restrictive security descriptors. As a result, low-privileged users can establish connections to the driver and access functions intended only for trusted processes. [RM1.1][MB1.2][RM1.3]User access to privileged functions could help an attacker take advantage of other weaknesses in the driver.

CVE-2026-12168 GFAC_Sys_x64.sys processes messages received through a minifilter communication port without properly validating user-supplied memory addresses before performing write operations. An attacker can provide a crafted request containing a desired destination address and data value, causing the driver to write arbitrary data to kernel memory. This write-what-where condition can be leveraged to modify sensitive operating system structures, such as process security tokens, resulting in privilege escalation to SYSTEM.

Impact

Multiple vulnerabilities in the driver may allow local attackers to crash the system, escalate privileges to SYSTEM, or execute unauthorized code. Due to insufficient access controls, privileged driver functionality is exposed to untrusted users, increasing the likelihood and impact of exploitation.

Solution

Unfortunately, we were unable to reach the vendor to coordinate this vulnerability. Users should restrict local access to trusted users and monitor systems for unauthorized interactions with GFAC. Where available, games that utilize GFAC should be disabled or removed until an update is available to address the identified vulnerabilities.

Acknowledgements

Thanks to Lucian Alexandru Necula for identifying and disclosing these vulnerabilities. This document was written by Michael Bragg.

Vendor Information

One or more vendors are listed for this advisory. Please reference the full report for more information.

Other Information

CVE IDs: CVE-2026-12168 CVE-2026-12166 CVE-2026-12167
Date Public: 2026-07-02
Date First Published: 2026-07-02
Date Last Updated: 2026-07-02 15:07 UTC
Document Revision: 4

Anton’s Security Blog Quarterly Q2 2026

βœ‡Anton on Security
By: Anton Chuvakin
30 June 2026 at 20:16

My Anton’s Security Blog Quarterly covers both Anton on Security and my posts from Google Cloud blog, Google Cloud community blog, and our Cloud Security Podcast (subscribe on Spotify, now withΒ VIDEO).

Top 10 posts with the most lifetime views (excluding paper announcement blogs):

  1. Anton’s Alert Fatigue: The Study [A.C.β€Šβ€”β€Šwow, this is still #1 now! Awesome! Perhaps I need more of such deepΒ studies]
  2. Security Correlation Then and Now: A Sad Truth AboutΒ SIEM
  3. Can We Have β€œDetection asΒ Code”?
  4. Detection Engineering is Painfulβ€Šβ€”β€Šand It Shouldn’t Be (PartΒ 1)
  5. Revisiting the Visibility Triad for 2020 (update for 2025 isΒ here!)
  6. Beware: Clown-grade SOCs StillΒ Abound
  7. Why is Threat Detection Hard?
  8. Top 10 SIEM Log Sources in RealΒ Life?
  9. A SOC Tried To Detect Threats in the Cloud … You Won’t Believe What HappenedΒ Next
  10. Log Centralization: The End IsΒ Nigh?

Top 5 posts with paper announcements:

  1. New Paper: β€œFuture of the SOC: SOC Peopleβ€Šβ€”β€ŠSkills, Not Tiers” (paper 2 of theΒ series)
  2. New Paper: β€œFuture of the SOC: Evolution or Optimizationβ€Šβ€”β€ŠChoose Your Path” (Paper 4 of 4.5) (one more paper coming later in 2026 … we are in reviewsΒ now!)
  3. New Paper: β€œFuture of the SOC: Forces shaping modern security operations”
  4. New Paper: β€œFuture Of The SOC: Process Consistency and Creativity: a Delicate Balance” (Paper 3 ofΒ 4)
  5. New Paper: β€œAutonomic Security Operationsβ€Šβ€”β€Š10X Transformation of the Security Operations Center” (Our classic 2021 ASO paper! Still epic, still relevant)

3 random fun posts, must-read:

Top 7 Cloud Security Podcast by Google episodes (excluding the oldestΒ 3!):

  1. EP150 Taming the AI Beast: Threat Modeling for Modern AI Systems with GaryΒ McGraw
  2. EP75 How We Scale Detection and Response at Google: Automation, Metrics,Β Toil
  3. EP47 β€œMegatrends, Macro-changes, Microservices, Oh My! Changes in 2022 and Beyond in Cloud Security”
  4. EP153 Kevin Mandia on Cloud Breaches: New Threat Actors, Old Mistakes, and Lessons forΒ All
  5. EP109 How Google Does Vulnerability Management: The Not So SecretΒ Secrets!
  6. EP17 Modern Threat Detection atΒ Google
  7. EP156 Living Off the Land and Attacking Critical Infrastructure: Mandiant Incident DeepΒ Dive

Now, fun posts byΒ topic.

Security operations / detection & response:

Cloud security:

How Google Does Security (HGD)β€Šβ€”β€Šthe new master site How Google Does It: An inside look at cybersecurity:

(if you only read one, choose this one! BTW, we also have a lot of fun HGD podcasts)

AI security:

Fun presentations shared (nothing much newΒ here):

Enjoy!

Previous posts in thisΒ series:

Anton’s Security Blog Quarterly Q2 2026 was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

Stop Building a 2003 SOC with AI: A Modern People & Process Framework (Part 1)

βœ‡Anton on Security
By: Anton Chuvakin
29 June 2026 at 23:24

One particular aspect of an agentic or AI-powered SOC (but NOT β€œhumanless SOC”) has bothered me over the last few months: specifically, the people and process side of such a SOC. If you recall my blog posts (part 1, part 2 and this video) about AI SOC readiness, I hinted at certain elements of a traditional process stack and legacy personnel profiles (both technical and leadership) that make AI adoption inside SOC incredibly difficult.

So we (me and Augusto Barros @ Prophet Security) want to create a modernized people and process framework for a SOC powered by AI and intelligent agents. Otherwise, what I am observing is a lot of β€œrobotic horse pulls a buggy” kind of operationsβ€Šβ€”β€Šwhere everything is kept exactly the same as it was in 2003, but β€œAI SOC” tools are simply tacked on to perform some of theΒ tasks.

Gemini visual of old SOC with β€œAI SOC” tools

I believe that people and process components must change far more dramatically, and such changes are a critical requirement for achieving β€œstep change” SOC with AI capabilities. Simply adding AI tools and Ai agents to a 2003-style SOC will produce, at best, marginal results. Things would get better, but not better enough to counter the feared β€œbad guy withΒ AI.”

The SOARΒ Analogy

The analogy I want to use here is SOAR adoption from 10+ years ago. Back then, organizations simply shifted a few processesβ€Šβ€”β€Šor even just specific tasksβ€Šβ€”β€Što a machine, and then kept the rest of their operations exactly the same. Because of that, I observed a lot of SOAR tools being used strictly for alert enrichment or for dealing with one specific, isolated type of alert, like phishing. To follow this analogy to the present day, I now frequently see an β€œAI SOC” being utilized only for EDR alerts or only for phishing alerts (wow, what a coincidence!)

A First-Principles Approach

What I really want to build is a first-principles approach to the specific personnel, skills, processes, and practices required to run a true agentic SOC in the lateΒ 2020s.

Now, if you prefer incremental change, that is OK, I won’t judge. However, you must be aware that the same principles caused organizations to struggle with cloud adoption. People often hear that β€œlift and shift” is bad. Most consultants will tell you that β€œlift and shift” is fine as a first step, but you eventually need to modernize and take more steps. Unfortunately, many organizations never make that second step. The same risk applies to the AI SOC. 2003 SOC + AI = somewhat better 2003Β SOC.

BTW, many artifacts of the modern, engineering-powered SOCβ€Šβ€”β€Šwhich we covered in our now-famous ASO (Autonomic Security Operations) paper back in 2021sβ€Šβ€”β€Šapply here as well. In fact, if you recall, one of our core principles was: Humans build machines; machines do theΒ work.

In the context of an agentic SOC, that evolvesΒ into:

Today, humans build the machines with the help of other machines, and then the machines do the heavyΒ lifting.

So, our questions soΒ far:

  • What do humans do in an agenticΒ SOC?
  • What do entry-level humansΒ do?
  • What SOC processes stay the same despiteΒ AI?
  • What SOC processes can just go and vanish (triage)?
  • What processes get handed to machines?
  • Are there new processes forΒ humans?
  • What is the new human role for validation?
  • How do we check AI quality without fully redoing theΒ work?
  • How SOC metrics must change due to AI and agents? (someΒ ideas)
  • What do humans and machines do jointly? What does it mean, practically?
  • How to HITL in a SOC without breaking the humans or machines?
  • What is the effective mechanism for the human-to-AI feedback loop so that corrections actually improve future SOC performance?
  • Is β€œfully automated” detection engineering a realistic goal, or does the dependency on local, inconsistent environment context make it inherently a hybrid human-machine effort?
  • What do humans do before SOC (TI) and after SOCΒ (IR)?
  • What is the first step to move from a legacy SOC to an agenticΒ SOC?
  • Can we run legacy and agentic SOC structures in parallel during transition, or does this duplication create operational friction?
  • Is it easier to move from a modern non-AI SOC (aka β€œSOCless D&R”) to an AIΒ SOC?

Looking Ahead

This blog post is just the first part of the series. My goal here is simply to collect the right questions we need to be asking, but I promise we will provide concrete answers in upcoming posts. This research is being undertaken together with my former colleague, Augusto Barros, now at ProphetΒ Security

Related blogs:

Stop Building a 2003 SOC with AI: A Modern People & Process Framework (Part 1) was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

VU#936962: Multiple file parsing vulnerabilities in FastStone Image Viewer 8.3.0.0

βœ‡CERT Recently Published Vulnerability Notes
By: CERT
22 June 2026 at 20:41

Overview

Two vulnerabilities have been identified in FastStone Image Viewer 8.3 that may allow remote code execution or control-flow corruption when processing specially crafted image files. The affected components include the JPEG 2000 (JP2) parser and the PSD file parser. An attacker can exploit these vulnerabilities by causing the application to automatically or interactively process malicious image files.

Description

FastStone Image Viewer is a software tool for browsing, editing, and managing images, offering features like full‑screen viewing, batch processing, red‑eye removal, and a wide range of editing effects. It supports virtually all major image and RAW formats and includes conveniences like slideshows, comparison tools, scanner support, and screen capture.

CVE-2026-30040 A critical heap-based buffer overflow vulnerability exists in FastStone Image Viewer, versions 8.3 and earlier. The issue is triggered during the parsing of JPEG 2000 (JP2) files due to a malformed QCD (quantization default, 0xFF5C) marker in the FSViewer.exe process. By exploiting this flaw, a remote attacker can overwrite the EIP (instruction pointer) and execute arbitrary code in the context of the current process via a crafted JP2 file.

Notably, this issue does not require the victim to directly open the crafted JP2 file. When the application enumerates directories during automatic thumbnail generation, files within two directory levels are parsed by the JP2 decoder. If the malicious JP2 file is present within this enumeration range (for example in the user’s Downloads folder), the vulnerability is triggered automatically.

CVE-2026-30041 An integer overflow vulnerability exists in the PSD parser of FastStone Image Viewer, versions 8.3 and earlier. The vulnerability is caused by a lack of proper validation for the height value in PSD files, leading to a subsequent heap-based buffer overflow. Successful exploitation could allow a remote attacker to execute arbitrary code or cause a persistent denial-of-service (crash) via a crafted PSD file.

Impact

Successful exploitation of CVE-2026-30040 could allow arbitrary code execution in the context of the user running FastStone Image Viewer. Additionally, an attacker could exploit CVE-2026-30041 to overwrite the instruction pointer and control the program's execution flow, crashing the application or potentially enabling arbitrary code execution. The impact severity depends on the privileges of the user running the application. Code executed under elevated permissions would result in significantly higher risk.

Solution

Unfortunately, we were unable to reach the vendor for coordination, and a patch is not yet available. To limit the risk of this vulnerability, run the software using a restricted local account and enforce policies that prevent users from downloading or saving JP2 or PSD files from untrusted sources.

Acknowledgements

This vulnerability was disclosed by Sunghun Oh. This document was written by Bob Kemerer.

Vendor Information

One or more vendors are listed for this advisory. Please reference the full report for more information.

Other Information

CVE IDs: CVE-2026-30041 CVE-2026-30040
Date Public: 2026-06-22
Date First Published: 2026-06-22
Date Last Updated: 2026-06-22 18:41 UTC
Document Revision: 1

VU#226679: Microsoft WinRE allows for bypass of UEFI/BIOS password enforcement

βœ‡CERT Recently Published Vulnerability Notes
By: CERT
22 June 2026 at 18:16

Overview

Microsoft Windows Recovery Environment (WinRE) provides a mechanism for recovering and repairing Windows systems using an alternate boot environment. Under certain platform implementations, access to WinRE may allow an attacker to bypass firmware security controls, including administrator-configured UEFI/BIOS passwords. An attacker with physical or administrative access to a device may be able to leverage WinRE-related boot mechanisms to circumvent firmware protections and gain unauthorized access to system resources.

Description

Microsoft Windows versions 10 and 11 include the WinRE capability, a recovery platform that supports features such as the F11 recovery menu and the Reset this PC functionalities. WinRE is commonly used for system recovery, troubleshooting, and remote support scenarios.

When WinRE is invoked, the system reboots into a recovery environment that may use an alternate boot path from the standard operating system startup sequence. Depending on the platform and firmware implementation, the alternate boot path may not consistently enforce the same UEFI/BIOS security controls that are applied during a normal boot process.

A security concern has been identified in certain WinRE implementations where administrative UEFI/BIOS passwords may not be enforced during specific recovery operations. This inconsistency in the boot execution path may allow an attacker with physical access to a device to bypass firmware-level protections. Such scenarios are commonly associated with "Evil Maid" attacks, in which an attacker gains temporary physical access to an unattended system and modifies its boot configuration or security settings.

In UEFI-based systems, the UEFI boot manager supports the BootNext variable, which specifies a one-time boot target stored in non-volatile memory (NVRAM). The UEFI trust model assumes that only privileged software or the platform owner can modify NVRAM variables; however, the BootNext variable itself is not authenticated and takes precedence over the normal BootOrder configuration during the next boot cycle. When Secure Boot is enabled, firmware validates the integrity and signature of the boot application specified by BootNext before execution. The UEFI specification does not explicitly mandate a full platform reset when the BootNext variable is configured, leaving reset-handling and user authentication flows to the specific implementation. Consequently, the effectiveness of pre-boot security controls (such as UEFI/BIOS password protections and BitLocker full-disk encryption) can be bypassed via recovery environments like WinRE, provided a user has the privileges required to initiate such recovery.

Organizations with high security requirements for their devices should not rely solely on UEFI/BIOS passwords to protect systems where WinRE or such recovery environments are accessible to untrusted users. Additional controls should be implemented to protect against both physical-access and privileged-user attacks.

Impact

An attacker with access to the Windows Recovery Environment may be able to bypass administrator-configured UEFI/BIOS password protections on affected systems. Depending on the device configuration and firmware implementation, an attacker may also be able to perform actions that weaken or circumvent BitLocker full-disk encryption protections, potentially resulting in unauthorized access to sensitive data.

Solution

Microsoft has published an advisory related to recovery-environment hardening and secure boot configurations, including mitigations for vulnerabilities affecting WinRE mechanisms. Organizations should review applicable vendor guidance and evaluate whether their systems are susceptible to WinRE-based firmware security bypasses.

In addition to standard recommendations (e.g., enabling Secure Boot), the following mitigations are advised for highly sensitive systems:

  1. Disable or restrict WinRE on systems where recovery functionality is not operationally required.
  2. Require administrative authorization with ephemeral one-time access before enabling or invoking recovery environments.
  3. Enable BitLocker with TPM + PIN or TPM + Startup Key to ensure additional authentication is required during recovery and pre-boot scenarios.
  4. Enable restrictions of pluggable media with EFI System Partitions (ESP) and any modifications to sensitive items in UEFI NVRAM such as BootNext and BootOrder.
  5. Deploy endpoint detection and response (EDR) solutions or end-point restrictions that support pre-boot security along with remote attestation and measured boot technologies to detect or block unauthorized boot modifications.
  6. Implement physical security controls, including device locks, secure storage, tamper-evident protections, and chain-of-custody procedures for high-value systems.

These recommendations should be evaluated in accordance with organizational recovery requirements and operational constraints. Some of the recommendations were adapted from Eclypsium research blog

Acknowledgements

Thanks to Beatriz Fresno Naumova for reporting this vulnerability. This document was written by Vijay Sarvepalli.

Vendor Information

One or more vendors are listed for this advisory. Please reference the full report for more information.

Other Information

CVE IDs:
Date Public: 2026-06-22
Date First Published: 2026-06-22
Date Last Updated: 2026-07-06 19:15 UTC
Document Revision: 3

VU#457458: Vendor-signed UEFI applications found vulnerable to Secure Boot bypass

βœ‡CERT Recently Published Vulnerability Notes
By: CERT
18 June 2026 at 21:41

Overview

Multiple vendor-signed UEFI applications are vulnerable to Secure Boot bypass via a "Bring Your Own Vulnerable Driver" (BYOVD)-style attack. If a target system trusts the affected vendor’s certificate, an attacker can exploit these applications to execute arbitrary code during the early pre-boot phase before the operating system initializes. To mitigate this risk, system administrators should apply updates to the UEFI Forbidden Signature Database (DBX) that revoke trust in the affected vendor-signed binaries, preventing these vulnerable applications from executing during the boot process.

Description

The Unified Extensible Firmware Interface (UEFI) standard defines the modern firmware architecture used to initialize hardware and transfer control to the operating system during system startup. On systems with Secure Boot enabled, UEFI applications and drivers must be cryptographically signed and verified before execution. Trust for these signatures is established through several firmware-managed databases, including the authorized signature database (DB), which commonly contains certificates from original equipment manufacturer (OEM) vendors, operating system authorities, and other supply-chain partners in the UEFI ecosystem.

The UEFI shell is a command-line application that allows advanced users to interact directly with the UEFI environment to run diagnostics or special tasks prior to the operating system boot. Other UEFI applications, such as bootloaders, manage the operating system startup sequence or load specific drivers before the main OS initializes. Some of these applications possess functionalities that can manipulate system memory, modify sensitive NVRAM variables, or load raw drivers.

If a vendor-signed application inadvertently exposes these capabilities without strict access controls, attackers can abuse them to circumvent Secure Boot policies and execute unverified code. This exposure effectively results in an early compromise of the pre-boot environment, bypassing the Secure Boot policy.

Researchers from ESET identified multiple UEFI applications vulnerable to this type of abuse. To neutralize the risk, the affected binaries will be added to vendor-specific DBX revocation lists to prevent them from executing on the target systems.

Impacted UEFI Applications
[Vendor, Application and vulnerable function
Authenticode SHA hash
SHA256 file hash]
 
Acer `GRUB2` insmod
71DCE405964C67779DB92DBC01F683D6E29075AB
6cc0e9501420ec036f0ad74df2d17f4d6360f26585f265042537b9f8c2780c30
Acer `UEFI shell` mm,dmpstore
D275C2DFD884D2B7842C7F861C527A9FFC6E59DD
b0af2158f11535d8458b8497a35e96d5afc76e43825f255d2d6aa2da74bad883
Acer `UEFI shell` mm,dmpstore
42C4923E676A9FD0A93C08631AD7A8244A8F2174
0784c30a83bfcc45bf42804e5729323987957f0a104fcb693d0ff10d76d5b42c
Acer `UEFI shell` mm,dmpstore
04BE47C873F116B85111FBF8EE9191C87CEE2619
b0af2158f11535d8458b8497a35e96d5afc76e43825f255d2d6aa2da74bad883
Acer Emdoor `UEFI shell` mm,setvar
CD5E3EAD6F78526BF9301DEEF66906618654F604
14a493007443c72050ce644562db1470e36bf9d04baf5dec6b046e32cbdbb61b
AMD `UEFI shell` mm,dmpstore
744565FBB35DB710BCC1547292204763C731DC55
58bc1e460a1b7e18e6ad12dae8020c38bd7b3d6217130dd127ae232e4b248406
ASUS schenker-tech.de(XMG) `UEFI shell` mm,dmpstore
DC18D31E46A541C9E42F9588554ADDC7DECE124B
61ee9a23c366a102ceb34c78af7816413769791658cdb668b02cb81ec94f7c70
ECS `UEFI Shell` mm,dmpstore
59BA2B5C239AF3CC7FCE74AA5E65AAA8CE3C454F
81da15d6acdfb7868ecea44d41c869c2295603af9a44a2d106d4c0e57d66908
Getac `UEFI Shell` mm,dmpstore
35FBD8ED5ED31D281A6146360CDEFE7E8CEC31DA
09d895bb03bdac3188ef61b09ab72b99492cfd0b785cbc3eb2eb75657a2f9fa0
GIGABYTE Maibenben `UEFI Shell` mm,setvar,dmpstore
6CC172CBFEEA24B2806B477F8EDF897334ECC486
2944da098861619e21b522a642235bb2ec189ff20ef96e100b2ffdd9a39c3416
Toshiba `UEFI Shell` mm,dmpstore
2EAE2807A4265D9C30EECA68A8C59C7A6D1ACFE7
cad246ae8a5db51f32f128896ccef5efc30e5d65c9d9722b449988d43da53d51
Uniwill Maingear schenker-tech.de(XMG) `UEFI Shell` mm,dmpstore
8CED62F9BD5C987A80598DA1E13414391BBB1ADE
55682bec887134a2ccaa2cd5458cd3fe6395ea93bb88c9dc541806428b14fc66

Impact

This vulnerability only impacts systems where the specific affected vendor's certificate is trusted within the UEFI Authorized Signature Database (DB). On such systems, an attacker with administrative privileges or physical access could leverage the vulnerable application to bypass Secure Boot protections and execute arbitrary code before the operating system loads.

Code executed during this early boot phase can achieve persistent platform compromise, including the ability to load unsigned or malicious kernel components that survive system reboots and operating system reinstallations. Because this activity occurs before the operating system and endpoint security products initialize, malicious code executed through this technique may completely evade detection by standard security controls and endpoint detection and response (EDR) solutions.

Solution

Apply the latest firmware and software updates provided by your hardware or software vendor. Please refer to the Vendor Information section for details. Updated software packages will replace vulnerable UEFI applications with corrected versions that incorporate the latest upstream security fixes.Additionally, administrators should update and verify the UEFI DBX on affected systems to ensure the vulnerable binaries are revoked and can no longer execute during the boot process.

Acknowledgements

Thanks to Martin Smolar of ESET for researching and reporting this vulnerability. This document was written by Vijay Sarvepalli.

Vendor Information

One or more vendors are listed for this advisory. Please reference the full report for more information.

Other Information

CVE IDs:
Date Public: 2026-06-18
Date First Published: 2026-06-18
Date Last Updated: 2026-06-23 17:02 UTC
Document Revision: 2
Received β€” 10 July 2026 ⏭ News
❌