The Bug Report – August 2026 Edition

By Jonathan Omakun · September 3, 2026

Why am I here?

Sharpen your pencils and pull out those fresh notebooks; we're back with the bug report! Half the world is squeezing the last drops of joy out of their summer vacations, and the other half is on the back-to-school grind, but here at the Advanced Research Center, school is always in session. Instead of buying new backpacks and highlighters, our team has been picking out the most interesting bugs of the month for you to enjoy. So, grab a juice box, take your seat in the front row, and let’s review the syllabus.

August brings us seven bugs worth paying attention to. Nearly all of these are being actively exploited in the wild, and a few even have publicly available POC code to play with, so the threats are far from hypothetical:

CVE-2026-68820 Microsoft Windows Ancillary Function Driver for WinSock, Use After Free

CVE-2026-72898 Metabase Metabase, SQL Injection

CVE-2026-16812 Arista Networks VeloCloud Orchestrator On-Prem, OS Command Injection

CVE-2026-66066 Ruby on Rails Action Pack Active Storage, Initialization of a Resource with an Insecure Default

CVE-2026-71362 Adobe Commerce, Incorrect Authorization

CVE-2026-18577 N-able N-central, Authentication Bypass

CVE-2026-44105 Phoenix Contact CHARX SEC, Insertion of Sensitive Information Into Log File

CVE-2026-68820: The job offer you can't refuse (because it owns your kernel)

What is it?

Deep in the bowels of Windows networking sits afd.sys, the Ancillary Function Driver that's been quietly shuttling WinSock traffic since roughly the dawn of time. Like a lot of old infrastructure, it's got a race condition problem: under the right timing conditions, a per-socket state object gets freed while something else still holds a reference to it. Classic use-after-free (CWE-416), except this one hands out a kernel read/write primitive to whoever wins the race.

Check Point Research found and disclosed this one on July 28, 2026, and Microsoft patched it on schedule during the August Patch Tuesday. Except "on schedule" doesn't mean "before anyone noticed;" Lazarus Group was already using it as a zero-day since early July.

The attack chain is where this gets genuinely cinematic. It starts with the oldest trick in the DPRK playbook—Operation Dream Job—a spear-phishing lure dressed up as a job offer, this time bundling a trojanized PDF viewer impersonating security vendor Enveil. Victims install "SecurityPDF," which drops the Troy backdoor, which in turn pulls MISTPEN, an in-memory downloader that fetches its next stage over the Microsoft Graph API/OneDrive, because nothing blends in on a corporate network quite like traffic to Microsoft's own cloud. The C2 channel even negotiates post-quantum key exchange (Kyber/ML-KEM), which is either delightfully paranoid or a sign these guys are planning for a very long operational shelf life.

The actual exploit, Afd4Eop12_x64.dll, never touches the disk. It's loaded straight into memory, wins the afd.sys race, and elevates to SYSTEM. From there, Lazarus injects FudModule v3.1, a kernel rootkit that reaches into msiexec.exe and starts flipping off your defenses one by one: EDR telemetry, minifilters, crash dumps, and even Smart App Control get quietly neutered. Persistence is handled by ForestTiger. It's a full toolkit, not a one-off exploit.

Who cares?

Everyone running a supported version of Windows. Technically, the vulnerable code spans the full 10/11/Server matrix back to 2012. Practically, Lazarus's compiled exploit only fires on Windows 11 builds 26100/26200, which narrows the active blast radius considerably, though the underlying bug remains exploitable elsewhere.

Confirmed victims span France, Germany, Brazil, and India, concentrated in defense, aerospace, and aviation. These are sectors Lazarus has been quietly harvesting IP from for years under the "Dream Job" banner. One French victim was notably repurposed as a launchpad for further spear-phishing, which is the digital equivalent of a burglar using your house to case the neighborhood.

No public proof of concept (PoC) exists currently. It’s a nation-state-exclusive exploit, not something you'll find on GitHub with a README and a targets file. That actually makes it more concerning for defenders: no crowd-sourced detection signatures, no script-kiddie noise to hide in, just a quiet, surgical capability sitting in one APT's toolbox.

What can I do?

Patch now: Microsoft released patches in their August Patch Tuesday drop to close this hole. If you haven't applied them, do that before reading the rest of this report.

Watch for EDR blind spots: If your telemetry suddenly goes quiet on a host that just spawned msiexec.exe doing unusual things, that might not be a coincidence; it could be FudModule.

Retrain your HR-adjacent staff (and everyone else) on job-offer phishing, especially anything bundling a "security" PDF viewer from a vendor you didn't ask for.

Trellix customers: Trellix Network Security (NX)/MVX contains detection for this vulnerability. Please ensure that you update to at least security content version 1684.182. To enrich hunting efforts, Trellix Insights contains IOCs related to campaigns/exploitation of this vulnerability.

CVE-2026-72898: Metabase's password reset endpoint has a SQL-shaped skeleton key

Metabase, the popular BI/dashboarding tool, shipped a password reset endpoint that trusted its JSON input a little too much. POST /api/session/reset_password accepts a user-id field, and due to insufficiently restricted field handling, an attacker can hand it a HoneySQL :raw object instead of a plain integer. HoneySQL, Metabase's SQL-building library, dutifully executes that raw payload as SQL. Congratulations, you've turned a "forgot your password" form into a database console.

The exploit is a tidy three-act play:

1. Unauthenticated injection - craft the :raw payload as user-id, fire it at the reset endpoint.


2. Side-channel success - the endpoint still returns HTTP 400 (the intended response body never renders), but the injected SQL executes anyway, forging a legitimate admin session directly into the core_session table.


3. Walk in the front door - attacker grabs the forged session and authenticates via the X-Metabase-Session header. Full admin access, no password required, no visible success page to tip off a lazy WAF.

That HTTP 400 masking is the sneaky part. Anyone watching response codes for "attack succeeded" signals would see a wall of 400s and move on, never realizing the side effect of that failed-looking request was a fully forged admin session sitting in the database.

A publicly available PoC features as a deployable attack tool, complete with bulk multitarget scanning support via a targets file. Whoever wrote it clearly knew the core_session/core_user schema, the SHA-256 session token hashing scheme, and how to fingerprint patched instances before firing.

Looking at the public PoC makes it abundantly clear how devastatingly simple this attack is to execute. The exploit essentially packages a raw SQL injection directly into the JSON dictionary. Let's look at the payload builder:

Notice how it leverages HoneySQL's {"select": {"raw": sql}} feature. The attacker generates a UUID locally (session_id), hashes it, and injects a SQL string that forcefully creates a new session tied directly to the first active superuser it can find in core_user. By passing this into the user-id field, the attacker bypasses all standard auth mechanisms, allowing them to instantly hijack the platform.

Who cares?

Anyone running Metabase below the patched line (0.58.24 / 0.59.21 / 0.60.17 / 0.61.11 / 0.62.9 / 0.63.5) is sitting on a skeleton key to every data source their instance connects to. This isn't an OS-level RCE, but "read access to every connected database's credentials and contents" is arguably worse for a BI tool whose entire job is aggregating sensitive data.

And exploitation is not theoretical. The CVE has been added to the Cybersecurity and Infrastructure Security Agency’s (CISA) confirmed Known Exploited Vulnerabilities (KEV) entry, exploited as a zero-day before wide disclosure, with at least five Metabase Cloud tenants compromised pre-patch. n8n disclosed exposure of 136 customer records: usernames, emails, cloud passwords, API-key hashes, and Slack tokens.

There's a possible ShinyHunters connection via an extortion-blog listing, though it's unconfirmed. Take that attribution with appropriate skepticism, but don't dismiss the possibility that this got scooped up by a group that specializes in exactly this kind of mass-credential harvesting.

What can I do?

Patch immediately to the fixed branch for your version line. (Note: version numbers have varied slightly across sources. Cross-check against Metabase's official advisory before treating any single list as gospel.) 

Hunt your logs for the tell-tale 400→200 sequence on /api/session/reset_password followed by session-endpoint activity, a 400 that's immediately followed by successful authenticated requests is the fingerprint. 

Rotate everything Metabase could see: DB credentials, API keys, Slack tokens, cloud passwords if you were running a vulnerable version with any internet exposure. If you're downstream of a Metabase-connected service, rotate credentials now. Don't wait for a breach notification email. 

Restrict admin session usage and review core_session table entries for anomalous or unexplained admin sessions created outside normal login flows. 

CVE-2026-16812: Arista's "local-only" admin panel wasn't, actually, local-only

What is it?

Somewhere in the development of Arista's VeloCloud Orchestrator (VCO), the brain of their SD-WAN deployments, a feature explicitly designed for local-admin-only use got exposed over the public HTTPS interface, with no authentication gate in front of it. The result is about as bad as networking vulnerabilities get: unauthenticated, network-reachable, arbitrary OS command execution with the privileges of the VCO host process.

The CVSS is a perfect 10.0, complete with a scope change, because VCO doesn't just manage itself; it also centrally orchestrates downstream VeloCloud Edge devices and gateways. Compromise the orchestrator, and you've effectively compromised the entire SD-WAN fabric it controls. It's less "one broken lock" and more "the master key to every door in the building, including the ones the building doesn't even know it has yet."

Who cares?

Anyone running VeloCloud Orchestrator On-Prem below the patched versions (< 7.0.0.1, <6.1.3.4, <5.2.3.14, < 6.4.2.4). Notably, Arista's hosted/dedicated offerings were already pre-patched, meaning the exposed population is specifically self-managed on-prem deployments. That's an important distinction: if you outsourced your SD-WAN management to Arista's cloud, you likely dodged this one. If you self-host, you were likely the target.

This landed in CISA's KEV list the same day it was published, a strong signal that exploitation was already happening in the wild before or immediately upon disclosure, not some slow-burn discovery. The targeting profile skews toward telecom, which makes sense, since SD-WAN infrastructure is disproportionately telecom and managed-service-provider territory. 

We have some attacker IPs but no named actor or public PoC yet. This one's flying somewhat under the radar despite the maximum severity score, likely because it's a less "sexy" target than consumer software but a very juicy one for anyone wanting to pivot across an entire SD-WAN deployment.

What can I do?

Patch to 5.2.3.14 / 6.1.3.4 / 6.4.2.4 / 7.0.0.1 or later immediately. This is a max-severity, actively exploited, unauthenticated RCE. There is no good reason to delay. 

Audit internet exposure of your VCO admin interface right now. If it's reachable from the public internet at all, that's the root problem regardless of patch status. 

Block the known attacker IPs at your perimeter as an interim measure. Trellix Insights contains IOCs related to campaigns/exploitation of this vulnerability.

Check downstream edge devices/gateways for signs of configuration drift or unauthorized changes. Remember, VCO compromise has a scope change into everything it manages. If you're an MSP or telecom operator, treat this as a supply-chain event. A single compromised orchestrator can cascade into every customer network it touches. 

CVE-2026-66066: KindaRails2Shell: When your image uploads start uploading themselves access

What is it?

Ruby on Rails' Active Storage feature lets applications process user-uploaded images through variant transformations (resizing, cropping, etc.), typically backed by the libvips image library. This CVE, nicknamed "KindaRails2Shell", chains three separate weaknesses into full remote code execution, and it's the kind of vulnerability that makes you appreciate just how much trust gets extended to a file that claims to be "just a picture."

Stage one: An attacker crafts a polyglot file, valid as both a MATLAB5.0 file and an HDF5 container, exploiting libmatio's external dataset pointer feature. When Rails runs this file through image-variant rendering, libmatio dutifully follows that pointer and reads arbitrary files off the server, including things like /proc/self/environ, which conveniently contains environment variables—including credentials.

Stage two: Among those leaked secrets is Rails' secret_key_base, the seed used to derive the HMAC signing key (via PBKDF2-HMAC-SHA256) that Rails uses to cryptographically sign things like variation parameters. Leak the key, and you can now forge anything Rails would normally trust as "signed by us."

Stage three: With a forged, validly signed variation parameter in hand, the attacker drives the ImageProcessing chain builder into calling Kernel#spawn or instance_eval, turning an image-resize operation into an arbitrary shell command. It's the vulnerability equivalent of forging a hall pass, then using that same forged hall pass to unlock the principal's office.

Two independent researchers have published working PoCs. One of them is a genuine weaponized mass-scanner built for threaded, concurrent multitarget exploitation, notably capturing command output in-band (no need for an out-of-band callback server, which makes detection harder). A second PoC is more restrained, loopback-only, and confirms RCE via an OOB curl callback, useful for safer validation testing.

To fully appreciate the damage, just look at how cleanly the weaponized PoC handles the final step. Once the payload forces Active Storage to spit out the secret_key_base in the PNG's pixel array, the script generates a malicious cryptographic signature natively:

By extracting the secret key and deriving the verifier key, the attacker dynamically crafts an Active Storage variation envelope that triggers Ruby's instance_eval. That perfectly valid, cryptographically sound signature tells the server it's safe to process the request, handing the attacker an instant, stealthy reverse shell.

Who cares?

Any Rails app (≥7.2, <7.2.3.2; ≥8.0, <8.0.5.1; ≥8.1.0.beta1, <8.1.3.1) that processes untrusted image uploads through Active Storage with a libvips backend is exposed. Given how common image uploads are—avatars, product photos, document attachments—this touches a huge swath of the Rails ecosystem, and it's confirmed to be exploited in the wild with a KEV listing to back it up.

The real headline is the existence of a purpose-built mass scanner. This isn't a targeted, bespoke exploit chain reserved for high-value victims; it's built for spray-and-pray sweeps across the internet. If your Rails app takes image uploads and you haven't patched, assume you're already on someone's scan list.

What can I do?

Patch Rails to 7.2.3.2 / 8.0.5.1 / 8.1.3.1 or later. 

Upgrade libvips to ≥8.13, which closes the external-dataset-pointer file-read vector at the library level. 

Set VIPS_BLOCK_UNTRUSTED=true if you can't patch right now. This blocks the untrusted-file-read primitive that kicks off the whole chain. 

Rotate your secret_key_base if there's any chance you were running a vulnerable version with public image uploads. Assume it may have leaked. 

Monitor for the mass-scanner signature. This could include unusual polyglot MAT/HDF5-style uploads hitting image-processing endpoints, especially from automation-flavored user agents or in rapid multitarget bursts. 

If your architecture allows it, restrict variant processing to a sandboxed/isolated worker to limit the blast radius even if the chain succeeds. 

Trellix customers: Trellix Network Security (NX)/IPS contains detection for this vulnerability. Ensure you are updated to at least security content version 1685.166, and the HTTP Response option is enabled.

CVE-2026-71362: Magento's account edit page will happily let you be someone else

What is it?

Adobe Commerce/Magento's customer account edit controller (Magento\Customer\Controller\Account\Edit) has a session-handling flaw that lets an authenticated attacker rebind their own logged-in session to point at an arbitrary other customer_id. It's an incorrect authorization (not injection, not memory corruption), the kind of bug that exists because two components trust each other's assumptions a little too much.

The attack is relatively low-effort for the payoff:

1. Attacker self-registers a completely normal, legitimate account.
2. During the account-edit flow, they exploit session poisoning in customer_form_data handling to rebind their authenticated session to a victim's customer_id.
3. They confirm takeover by pulling the victim's PII straight from the account edit form or the section-data API. No password required, no OTP, no email confirmation.

A complete and functional PoC is publicly available, showing the interplay between DataObjectHelper::populateWithArray() and Magento's Customer\Model\Session at a level consistent with source-code review or patch-diffing.

Who cares?

Every Magento/Adobe Commerce store with self-registration enabled is a candidate victim, which is most of them, since customer self-registration is table stakes for e-commerce. This is confirmed under active exploitation right now, which is a particularly bad combination: retail/e-commerce sites hold exactly the kind of PII (names, addresses, order history, sometimes partial payment info) that makes this bug immediately monetizable.

While unconfirmed, the profile fits classic Magecart-style operators, actors who specialize in squeezing customer and payment data out of e-commerce platforms. Given the ease of exploitation (self-registration + a rebind trick, no exotic tooling required) and the working public PoC, this is very much an active-incident-priority bug, not a "patch when convenient" one.

What can I do?

Apply Adobe's security patch immediately. This is listed as an active-incident priority for unpatched internet-facing stores. 

Audit account-edit session logs for anomalous session rebinding patterns, specifically sessions where the acting customer_id changes mid-session without a corresponding logout/login event.

Force session invalidation on password changes and account edits as a general hardening measure, even post-patch.

Review recent account activity for signs of mass PII scraping via the account edit form. Look for accounts touching many customer_id values in rapid succession. If you're a shopper, this is a good excuse to check your recent account activity on any Magento-based store and change your password if anything looks off.

CVE-2026-18577: N-able N-central's second attempt at fixing auth still left the door ajar

What is it?

This is the sequel nobody asked for: CVE-2026-18577 is what happens when the fix for a previous authentication bypass (CVE-2026-18556) doesn't quite finish the job. The original vulnerability got patched, sure, but an alternate API path into the same authentication logic was left standing, letting attackers bypass auth entirely with no credentials and no user interaction required. It's the security equivalent of fixing the front door lock while leaving the side door propped open with a brick.

N-able's own MDR product (Adlumin) is actually the one that caught this. It spotted exploitation in the wild on July 31, 2026, just two days before N-able shipped a hotfix on August 2, 2026, with CISA adding it to KEV the very next day and setting a Federal Civilian Executive Branch (FCEB) remediation deadline of August 2, 2026. That's about as tight a detection-to-mandate timeline as you'll see, which tells you how seriously this one was taken internally.

Who cares?

N-central is a remote monitoring and management (RMM) platform. The kind of tool MSPs use to manage dozens or hundreds of customer environments from a single pane of glass. Authentication bypass on an RMM platform isn't just "one company got popped," it's a pivot point into every customer that MSP manages. This is the supply-chain nightmare scenario for managed service providers.

Post-exploitation behavior observed in confirmed compromises follows a consistent, almost businesslike pattern: 

This CVE carries the highest EPSS score in the entire set (0.02529, 83rd percentile). This is a real signal that predictive models see continued exploitation as likely, on top of the confirmed compromises already logged.

What can I do?

Patch to 2026.3.1.7 immediately if you haven't already. The FCEB deadline of August 6, 2026, has already passed, so if you're reading this after that date, you're overdue. 

Hunt for the IOC set published by N-able.

Check for rogue cloudflared tunnels on N-central hosts. This persistence mechanism is designed to survive a straightforward patch-and-move-on response. 

Inspect user Documents folders for stray svchost.exe, a binary that has no business being anywhere near a user profile directory. 

Audit "Take Control" session logs for unusual activity, especially sessions initiated outside normal admin working patterns.

MSPs specifically: Treat this as a potential multicustomer incident, not a single-tenant one. Verify no customer environments show signs of pivot activity originating from your N-central instance. 

Trellix customers: Trellix Insights contains IOCs related to campaigns/exploitation of this vulnerability.

CVE-2026-44105: Your EV charger's diary has your password written in it

What is it?

The Phoenix Contact CHARX SEC series (SEC-3000/3050/3100/3150) are industrial EV charging controllers, and like a teenager who writes their diary password on the diary itself, they've been logging the credentials for the local user-app account in cleartext, directly in device log files. CWE-532, "Sensitive Information in Log File," is about as self-explanatory as vulnerability classes get: If you can read the logs, you can read the password. Once an attacker has local log access, extracting the user-app credentials and SSHing in becomes trivial. The account itself is low-privilege, which caps the confidentiality and integrity damage, but availability is a different story. This is an EV charging controller, and disrupting availability here doesn't mean "a webpage goes down;" it means charging stations potentially stop charging vehicles.

Who cares?

Fleet operators, charging network providers, and anyone running CHARX SEC controllers on firmware below 1.9.1. This sits squarely in the automotive/ICS space, and with EV charging infrastructure expanding rapidly, it's a solid reminder that the critical infrastructure attack surface is growing right alongside the green-energy transition. Attackers don't care whether the thing they're disrupting runs on gas or electrons.

To be clear about the actual risk level: there's no known exploitation, no public PoC, and the attack requires local access to log files in the first place. This isn't an internet-facing zero-day; it's a "if someone already has a foothold, here's an easy privilege stepping stone" bug. Medium severity is the right call here, but it's worth keeping on the ICS watch-list given the sector's growth trajectory.

What can I do?

Update to firmware 1.9.1 (expected/targeted for August 12, 2026) as soon as it's available for your controller model. 

Restrict local/physical access to charging controllers and their management interfaces in the interim. This bug requires local log access, so cutting off that access closes the practical attack path even pre-patch.

Rotate user-app credentials after patching, in case logs were ever exposed to untrusted local users or processes.

Audit log retention and access controls: Logs containing credentials shouldn't be broadly readable regardless of whether this specific bug exists. 

ICS/OT teams: Add this to your EV-charging-infrastructure watch list even without active exploitation. The sector's expanding attack surface makes it worth proactive attention now rather than reactive scrambling later.

Discover the latest cybersecurity research from the Trellix Advanced Research Center.