DEV Community: Diego Diaz

Iran's Nimbus Manticore Deploys AI-Assisted MiniFast Backdoor via Phishing and SEO Poisoning

Diego Diaz — Tue, 14 Jul 2026 01:17:01 +0000

An Iranian state-sponsored hacking group is using artificial intelligence to build backdoors, then delivering them through poisoned Google search results and phishing emails targeting the aviation and software sectors. The campaign, attributed to Nimbus Manticore (also tracked as Screening Serpens and UNC1549), represents a notable escalation in both tradecraft and toolchain: AI-assisted malware development combined with SEO poisoning at scale.

What Happened

Research published in May 2026 by The Hacker News and Aviatrix Threat Research linked Nimbus Manticore to a sustained espionage campaign targeting aviation and software organizations across the United States, Europe, and the Middle East. The group — widely assessed as affiliated with Iran's Islamic Revolutionary Guard Corps (IRGC) — deployed two malware families: MiniFast, a compact backdoor built with AI assistance, and MiniJunk V2, an updated variant of a previously documented loader.

The campaign follows the joint U.S.-Israeli military operation against Iran earlier in 2026, suggesting the espionage push is at least in part retaliatory intelligence gathering. As Enigma Global reported, the lures impersonate legitimate organizations in the aviation and software sectors, using fake job offers, security alerts, and software download pages as initial infection vectors.

The Dual-Channel Delivery Chain

What makes this campaign operationally significant is its dual delivery infrastructure: phishing and SEO poisoning working in parallel.

Phishing arm: Targets receive carefully crafted emails impersonating recruiters, security teams, or vendor contacts. Attachments or links lead to trojanized installers — including a fake Oracle SQL Developer package, as GBHackers documented. The SQL Developer lure is particularly clever: developers and DBAs routinely download tooling from web sources, making the trojanized package a high-confidence infection vector.

SEO poisoning arm: The group manipulates search engine results to rank malicious pages above legitimate ones. When targets search for common enterprise tools, vendor documentation, or aviation-sector resources, the poisoned results appear at the top. Users click what looks like a legitimate download page and receive the malware payload instead. As NetCrook noted, this technique "meets users where they already expect to download tools" — bypassing email security entirely.

The infection chain follows a staged approach documented by Check Point Research:

February 2026: AppDomain hijacking used to deliver MiniJunk loader
March 2026: MiniFast backdoor deployed as the primary persistence mechanism
Ongoing: SEO poisoning distributes trojanized Oracle SQL Developer and other fake tools

AI-Assisted Malware: The MiniFast Factor

The most technically notable aspect of this campaign is the use of AI-assisted development for the MiniFast backdoor. According to Aviatrix's analysis, MiniFast exhibits code patterns consistent with AI-generated output — including unusual variable naming conventions, redundant but functionally correct logic blocks, and boilerplate structures that differ from the group's historically hand-crafted tooling.

This does not mean the malware is AI-written from scratch. Rather, it suggests Nimbus Manticore is using large language models to accelerate development: generating boilerplate, suggesting evasion techniques, or translating proof-of-concept exploits into deployable backdoors faster than manual coding would allow. The operational impact is clear: faster iteration, more variants, and a shorter window between vulnerability disclosure and weaponized exploit.

Impact

Sectors at risk: Aviation, software development, and by extension any organization whose employees download development tools from the web
Geographic scope: United States, Europe, and the Middle East
Delivery channels: Phishing email + SEO poisoning (dual-channel, defense-in-depth bypass)
Attribution: Nimbus Manticore / Screening Serpens / UNC1549 (IRGC-affiliated)
Malware families: MiniFast (AI-assisted backdoor), MiniJunk V2 (loader)
Context: Escalation following joint U.S.-Israeli military operation against Iran

How to Protect Yourself

Verify software downloads. Always download development tools (SQL Developer, VS Code extensions, etc.) from official vendor sites or verified package managers. Check digital signatures on installers before execution.
Monitor search results for SEO poisoning. Train employees — especially developers and DBAs — to verify URLs before downloading. SEO poisoning is invisible to email security tools because the initial vector is a search engine, not an inbox.
Block AppDomain hijacking. Monitor for unusual .NET AppDomain activity, particularly when legitimate applications load unexpected assemblies. Endpoint detection rules for AppDomain manipulation can catch the MiniJunk delivery stage.
Deploy behavioral detection for MiniFast. Signature-based detection lags behind AI-assisted malware variants. Behavioral rules — detecting unusual process injection, credential access, or C2 beaconing patterns — are more effective against rapidly iterated backdoors.
Restrict outbound connections from developer workstations. MiniFast establishes command-and-control connections. Network-level egress filtering limits the attacker's ability to exfiltrate data even if the initial infection succeeds.
Monitor for IRGC-nexus threat actor IOCs. Check Point Research, Aviatrix, and Enigma Global have published indicators of compromise for this campaign. Ingest these IOCs into your threat intelligence platform and SIEM.

The Bigger Picture

The Nimbus Manticore campaign is a case study in how state-sponsored threat actors are adapting to the AI era. The dual-channel delivery (phishing + SEO poisoning) shows operational maturity. The use of AI-assisted malware development signals a shift in the speed and scale at which APTs can iterate on tooling.

For defenders, the takeaway is clear: the attack surface is no longer just the inbox. It is the search engine, the download page, the developer toolchain. As AI lowers the barrier to building capable malware, the advantage shifts further toward volume and speed — and the organizations that survive will be the ones that assume every download is hostile until proven otherwise.

NGINX Rift: CVE-2026-42945 — An 18-Year-Old Heap Overflow Now Under Active Exploitation

Diego Diaz — Tue, 14 Jul 2026 00:17:01 +0000

It lived in NGINX's source code for 18 years before anyone noticed. Now it has a CVE, a codename, a public proof-of-concept, and active exploitation in the wild.

CVE-2026-42945, dubbed NGINX Rift, is a heap buffer overflow vulnerability in ngx_http_rewrite_module — one of the most widely used modules in the NGINX web server ecosystem. With a CVSS score of 9.2, it allows unauthenticated attackers to crash NGINX worker processes via crafted HTTP requests, and may enable full remote code execution when ASLR (Address Space Layout Randomization) is disabled on the target system.

As of May 26, 2026, VulnCheck and multiple researchers have confirmed active exploitation in the wild — just days after public disclosure.

What Is NGINX Rift?

The vulnerability is a heap buffer overflow in the ngx_http_rewrite_module, the module responsible for NGINX's rewrite directive. This module is foundational — it handles URL rewriting, redirections, and conditional request routing for virtually every NGINX deployment.

According to the NVD entry, an unauthenticated attacker can exploit this flaw by sending crafted HTTP requests that trigger the overflow in the worker process heap. The immediate effect is a worker process crash (denial of service), but the underlying heap corruption opens the door to arbitrary code execution on systems where ASLR does not provide sufficient protection — such as older kernels, containers with ASLR disabled, or embedded deployments.

What makes this vulnerability architecturally alarming: the rewrite module is not optional. It is compiled into NGINX by default and is used in the vast majority of configurations. If you run NGINX and use rewrite directives (or any framework/framework plugin that generates them), your attack surface includes this code path.

18 Years in the Wild Before Disclosure

Researchers traced the vulnerable code back to 2008, making this an 18-year-old bug that survived every audit, fuzzing pass, and security review NGINX has undergone in nearly two decades. That timeline means the flaw was present through NGINX's explosive growth period, powering an estimated 30-40% of the world's web servers at peak adoption.

The Makko technical analysis confirms the vulnerability can be triggered under specific rewrite configurations by an unauthenticated remote attacker. A working proof-of-concept exploit is publicly available, lowering the barrier for opportunistic exploitation significantly.

Impact: DoS Today, RCE Tomorrow

The confirmed and theoretical impact breaks down as follows:

Denial of Service (confirmed): Crafted requests crash NGINX worker processes. Repeated exploitation can exhaust the worker pool, taking down all services behind the NGINX instance.
Remote Code Execution (conditional): On systems where ASLR is disabled — common in containers, IoT devices, older Linux kernels, or misconfigured cloud instances — heap corruption can be weaponized for code execution with the privileges of the NGINX worker (typically www-data or nginx user).
Affected products: NGINX Open Source and NGINX Plus. KnightLi's analysis documents specific version ranges and rewrite configurations that trigger the overflow.
CVSS 9.2 — rated Critical. Unauthenticated, low complexity, no user interaction required.

The active exploitation confirmation from SecurityWeek and VulnCheck means this is not theoretical. Attackers are scanning for and hitting unpatched NGINX instances right now.

How to Protect Yourself

If you run NGINX — in production, staging, or even development — act on this today:

Upgrade your NGINX packages immediately. Patches are available for both NGINX Open Source and NGINX Plus. Check your vendor's advisory for the correct patched version for your deployment. If you cannot upgrade immediately, see the mitigation in step 4.
Audit your rewrite directives. Review every rewrite block in your NGINX configurations. The KnightLi analysis documents which specific rewrite patterns are most dangerous — audit those first.
Enable and verify ASLR. Ensure ASLR is active on all systems running NGINX: cat /proc/sys/kernel/randomize_va_space should return 2. This does not prevent the DoS but blocks the code-execution path.
Apply virtual patching if you cannot upgrade immediately. Use a WAF (ModSecurity, AWS WAF, Cloudflare) to block crafted HTTP requests that match the exploit signature. Akamai published pattern details you can use to craft WAF rules.
Monitor worker process health. Set up alerting for NGINX worker restarts and crash spikes. A single crash may be noise; a pattern of crashes on a production instance is exploitation.
Scan your exposure. Run VulnCheck, Qualys, or Nessus scans against your NGINX instances to confirm you are not running a vulnerable version. Do not assume your cloud provider has patched this for you unless they have explicitly confirmed it.

The Bigger Pattern

NGINX Rift is part of an uncomfortable trend in 2026: critical vulnerabilities discovered in foundational open-source code after more than a decade of undetected existence. The 18-year dormancy of this heap overwrite mirrors similar discoveries in cURL (CVE-2023-38545, 9 months preview), xz (CVE-2024-3094, 2 years planted), and now NGINX's rewrite core.

These are not bugs in obscure edge-case features. They are bugs in the infrastructure that the internet runs on — and attackers are getting faster at weaponizing disclosed vulnerabilities. The window between disclosure and active exploitation has collapsed from weeks to days.

If you run NGINX, patch today. Not tomorrow. Today.

TrapDoor: 34+ Malicious Packages Hit npm, PyPI, and Crates.io in Coordinated Supply Chain Attack

Diego Diaz — Mon, 13 Jul 2026 23:17:01 +0000

34+ malicious packages. 384+ versions. Three package ecosystems hit in coordinated waves. The TrapDoor supply chain campaign, first detected on May 22, 2026, is one of the most ambitious cross-ecosystem attacks against developer infrastructure this year — and it is still actively deploying.

What Happened

Starting at 8:20 PM UTC on May 22, 2026, a threat actor began publishing malicious packages across three of the world's largest open-source registries: npm (JavaScript/Node.js), PyPI (Python), and Crates.io (Rust). The campaign, tracked as TrapDoor by researchers at Socket, has sofar compromised at least 34 distinct packages spanning more than 384 published versions and artifacts.

The targets were not random. The malicious packages specifically targeted developer tooling in the cryptocurrency, DeFi, Solana, and AI/ML ecosystems — environments where a single stolen credential can drain wallets worth millions or inject backdoors into production pipelines.

According to Socket's analysis, the campaign is still active as of May 26, with new packages continuing to appear across all three registries. SOC Radar confirmed the credential-stealing payload targets environment variables, API keys, wallet seeds, and browser-stored tokens.

Technical Analysis: How TrapDoor Works

What makes TrapDoor technically notable is its post-publication payload mutation — a technique that most supply chain attacks skip entirely.

On PyPI, the malicious packages contain code that auto-executes on import. Instead of embedding a static payload, the package immediately fetches a remote JavaScript payload from an attacker-controlled *GitHub Pages domainusingnode -e`. As ByteIota documented, this lets the attacker update the malware's behavior *after publication without pushing a new package version — a detection-evasion step that blinds static analysis tools and most registry-level scanners.

On npm and Crates.io, the packages use similar typosquatting and dependency-confusion strategies, masquerading as legitimate utility libraries for blockchain interaction, AI model tooling, and Solana development. Once installed, the payload:

Harvests environment variables (.env files, shell profiles)
Extracts credentials from config files for AWS, GCP, Docker, Kubernetes
Scans browser profiles for stored session tokens and crypto wallet extensions
Exfiltrates collected data to attacker-controlled endpoints via HTTPS

Phoenix Security noted the campaign also exhibits characteristics of AI poisoning — several malicious packages target AI/ML pipelines where a compromised dependency could corrupt model weights or training data, not just steal credentials.

Impact

The scope is difficult to quantify precisely because the attack is ongoing, but the known numbers are significant:

34+ confirmed malicious packages across three ecosystems (some counts reach 36)
384+ published versions and artifacts
Three of the world's largest package registries (npm, PyPI, Crates.io)
Four high-value target sectors: crypto, DeFi, Solana blockchain, AI/ML
Earliest confirmed activity: May 22, 2026 at 8:20 PM UTC — and still active 4 days later

As CyberSecurityNews reported, the coordinated nature — hitting three ecosystems simultaneously with the same payload infrastructure — suggests a well-resourced threat actor, not an opportunistic script Kiddie. The Hacker News confirmed the campaign spans at least 384 related versions.

How to Protect Yourself

If you are a developer working with npm, PyPI, or Crates.io — especially in crypto, AI/ML, or blockchain — take these steps immediately:

Audit your dependencies. Check package.json, requirements.txt, and Cargo.toml for packages you don't recognize or that were recently added. Cross-reference against Socket's and SOC Radar's published IOCs.
Pin your dependencies using lockfiles (package-lock.json, Pipfile.lock, Cargo.lock) and verify checksums against known-good versions.
Scan for post-install scripts. Any npm package with a postinstall hook that reaches out to external domains during a node -e call should be treated as suspicious. PyPI packages that execute network calls on import are an immediate red flag.
Rotate credentials immediately if you have installed any previously unknown packages in the last two weeks. Assume environment variables, API keys, and wallet seeds are compromised.
Enable 2FA on package publishing. As of this week, npm now requires 2FA for publishing — but this only protects the supply side. On the consumption side, use tools like Socket, Snyk, or Dependabot to catch malicious packages before they enter your environment.
Monitor outbound network traffic from CI/CD pipelines and developer workstations. The TrapDoor payload communicates over HTTPS to attacker infrastructure — network-level detection can catch what static analysis misses.

The Bigger Picture

TrapDoor is the latest in an accelerating wave of supply chain attacks targeting open-source ecosystems. It follows the Mini Shai-Hulud worm that compromised TanStack and Mistral AI packages earlier this month, and the broader trend of threat actors treating package registries as primary distribution channels for malware.

The cross-ecosystem nature of TrapDoor — hitting JavaScript, Python, and Rust simultaneously — signals that attackers are no longer targeting a single language community. If your organization depends on open-source software (and whose doesn't?), supply chain security is no longer optional. It is infrastructure.

Gitea Container Registry Flaw Left 30,000 Private Image Repositories Wide Open for 4 Years

Diego Diaz — Mon, 13 Jul 2026 22:17:01 +0000

What Happened

For close to four years, every self-hosted Gitea instance with a private container registry had a gaping hole in its access controls: any person on the internet could pull private container images without an account, a password, or any credentials at all. The flaw, tracked as CVE-2026-27771, was disclosed on May 27, 2026, by NoScope, which estimates it affected more than 30,000 deployments across over 30 countries. The Hacker News confirmed the disclosure the same day, noting the vulnerability went undetected for close to four years.

A separate but related vulnerability, CVE-2026-20912 (CVSS 9.1), was disclosed earlier in January 2026. That flaw allowed authenticated users to link attachments from private repositories to public releases, effectively smuggling sensitive files past access controls. CVE Feed scored it 9.1 (CRITICAL). Both were fixed — CVE-2026-20912 in Gitea 1.25.4, CVE-2026-27771 in 1.26.2 — but the window of exposure stretches back years for most instances.

Technical Analysis

The root cause of CVE-2026-27771 is straightforward: when the Gitea container registry was configured to mark a repository as "private," the access control check was never actually enforced against unauthenticated requests. The private designation on a container repository did not deliver the protection operators reasonably expected. An unauthenticated HTTP request to pull an image succeeded exactly as if the repository were public.

This was not a misconfiguration. NoScope reproduced the bug on a default Gitea installation with a typical configuration. There is no evidence of a config toggle that was overlooked. The permission model in the container registry module simply failed to gate image pulls behind authentication.

CVE-2026-20912 is a different class of flaw: Gitea did not validate repository ownership when linking attachments to releases. An attacker with a low-privileged account could link a file uploaded to a private repository into a release on a different, public repository, making the attachment downloadable by anyone. The fix in 1.25.4 added strict ownership checks for release asset linking.

Who's Affected

NoScope's扫描 found the highest concentration of exposed instances in China, the United States, Germany, France, and the United Kingdom. Affected organizations included healthcare providers, aerospace manufacturers, retail infrastructure companies, and internet service providers. Any sector running Gitea with its built-in container registry and marking images as private was potentially exposed.

The impact of a leaked container image extends far beyond source code. A container image is a complete snapshot of a production environment: application code, dependencies, configuration files, and — all too often — hard-coded database credentials, API keys, internal service endpoints, TLS certificates, and environment variables pointing at production infrastructure. In many organizations, the image is effectively a blueprint of how production is wired together.

Forks of Gitea are also at risk: Forgejo has been confirmed vulnerable. Operators of any Gitea derivative should verify with their respective maintainers whether a patch has been backported.

How to Protect Yourself

1. Update Gitea to version 1.26.2 immediately — this patches CVE-2026-27771. If you also need the CVE-2026-20912 fix, ensure you are on at least 1.25.4 (1.26.2 includes both).

2. If you can't patch right now, apply the workaround: set [service].REQUIRE_SIGNIN_VIEW=true in your Gitea configuration file. This forces authentication for all registry access. Note: this is not suitable if you intentionally expose some container images publicly, as it will block all unauthenticated pulls.

3. Audit your container images for embedded secrets. Assume any image hosted on Gitea prior to patching may have been accessed. Rotate database credentials, API keys, TLS certificates, and any other secrets that were baked into images.

4. Scan your container registry pull logs. Look for unexpected anonymous pulls of private images dating back months or years. This is the only way to determine if the flaw was actively exploited before disclosure.

5. Review your secrets management pipeline. No secret should live inside a container image in the first place. Use runtime secret injection (Kubernetes secrets, HashiCorp Vault, cloud-native secret managers) rather than baking credentials into images at build time.

The Sable Angle

This is exactly the class of vulnerability that Sable's offensive team finds during infrastructure assessments — not through automated scanning alone, but by systematically exercising the access model from every angle the surface supports. The Gitea container registry flaw lived in a feature that "behaved exactly as documented" and drew no attention on a casual review. It took a methodology that tests assumptions, not just endpoints.

We have tracked similar registry and supply-chain exposures in our research on multi-ecosystem supply chain attacks and self-propagating npm worms. The pattern is consistent: the weakest link is rarely the encryption or the firewall. It is the access control that everyone assumed was working.

If your team runs Gitea, Forgejo, or any self-hosted container registry, book a pentest and let us find the gaps before someone else does.

Free Scan or Full Pentest? A Decision Guide for Founders Shipping a Vibe-Coded MVP

Diego Diaz — Mon, 13 Jul 2026 21:17:01 +0000

Every founder shipping an AI-built MVP hits the same fork in the road the week before launch. You ran a free security scanner, it gave you a grade, and now you're staring at a decision nobody prepared you for: is that scan enough, or do you actually need to pay someone to break into your app?

This guide answers that honestly. Not "you always need a $15,000 pentest" (you usually don't) and not "a free scan is fine, ship it" (it usually isn't). The right answer depends on three things: what you built, who your first users are, and what you're storing. Let's make the decision concrete.

The short version: a free scan tells you whether your front door is locked. A pentest tells you whether someone can walk through the walls. Most pre-launch founders need the first immediately and the second before they touch real customer data. If you're storing other people's data behind a login, you've already crossed the line where "free scan only" becomes negligent.

What a free scan actually checks (and what it can't)

A free security scan — including the free headers scan we run — is an unauthenticated, external look at your site. It hits your public URL the way an anonymous visitor (or a bot) would, and reports what it can see from the outside. That's genuinely useful, and it catches a surprising amount:

Missing security headers — no HSTS, no Content-Security-Policy, no X-Frame-Options. These are the difference between "clickjacking and XSS are hard" and "clickjacking and XSS are trivial." 89% of startup sites we scan fail this.
TLS / HTTPS misconfiguration — mixed content, weak redirects, missing HTTPS enforcement.
Information leakage in responses — verbose server headers, framework versions, stack traces leaking into production.
Obvious surface-level exposure — a public .env, an open /admin with no auth, a directory listing you forgot to disable.

Here's the hard limit: a free scan only sees what's reachable without logging in. It cannot test the logic behind your auth wall, because it doesn't have an account. And the most dangerous bugs in modern MVPs — the ones that actually leak your customers' data — live entirely behind the login.

What a free scan will never catch

If you built your MVP with Cursor, v0, Lovable, or Bolt, your most likely catastrophic bug is BOLA (Broken Object-Level Authorization, also called IDOR). It's when a logged-in user can read or modify another user's data by changing an ID in a request. We scanned 100 vibe-coded apps and 73 of them had a BOLA. A free external scan finds zero of them, because finding one requires logging in as User A and successfully fetching User B's records.

Here's the bug that ends startups, and why a scanner can't see it:

// app/api/invoices/[id]/route.ts — the auth check is there...
export async function GET(req, { params }) {
  const session = await getServerSession(authOptions)
  if (!session) return Response.json({ error: 'unauthorized' }, { status: 401 })

  // ...but the OWNERSHIP check is missing.
  const invoice = await db.invoice.findUnique({ where: { id: params.id } })
  return Response.json(invoice)
}

To a scanner, that endpoint returns 401 Unauthorized — it looks secure. To a logged-in attacker iterating /api/invoices/1 → /api/invoices/2, it returns every customer's billing data. The fix is one clause (where: { id: params.id, ownerId: session.user.id }), but no unauthenticated tool can tell you it's missing.

The same blind spot applies to the rest of the bugs that matter most after launch:

Supabase / Firebase tables without Row-Level Security — the public anon key in your client bundle can read tables you never meant to expose. 83% of exposed Supabase instances have this.
Privilege escalation — a normal user flipping a role field, or hitting an admin route that only checks "logged in," not "is admin."
Auth-flow flaws — password reset tokens that don't expire, session fixation, OAuth state that isn't validated.
Injection behind forms — SQL/NoSQL injection in a search box that the scanner never authenticated past.
Business-logic abuse — negative quantities, coupon stacking, race conditions on credit. No automated tool understands your business rules.

The decision framework

Run the free scan first, always. It's free, it takes three seconds, and if you fail the headers check you have homework before anything else is worth doing. Then use this to decide what comes next.

A free scan is enough (for now) if ALL of these are true:

Your app is a static or marketing site with no login and no user data.
You're pre-users — a waitlist or a landing page, nothing behind auth yet.
You store no personal data, no payments, no credentials belonging to anyone but you.

If that's you, fix your headers, enable HTTPS properly, and get back to building. Come back when you add a login.

You need a real test the moment ANY of these is true:

You have a login and a database — the instant users can create accounts, BOLA and broken access control become your #1 risk, and only an authenticated test finds them.
You store customer PII, health, financial, or messaging data — a single IDOR here is a disclosure email and possibly a regulatory event.
You're taking payments or handling money/credits — business-logic abuse is invisible to scanners and expensive when found in production.
A customer or investor is asking about security — "we ran a free scanner" is not an answer to a B2B procurement questionnaire.
You built it with an AI assistant and never wrote the auth middleware yourself — the failure modes are predictable and consistent, which is exactly why they need a human to chase the chains.

"Real test" doesn't have to mean a $15,000 enterprise pentest

This is where founders freeze. They assume the only options are "free scanner" and "hire a Big Four firm for the price of a developer." There's a middle that's built exactly for pre-launch startups: a focused, authenticated pentest scoped to your actual app — your auth flows, your API objects, your data isolation — not a 200-page compliance artifact you don't need yet.

That's the gap Sable fills. A real human runs an authenticated test against your stack, calibrated for indie and early-stage codebases, and you get back the findings that actually matter — with proof-of-concept repos so you can see and reproduce the bug, not just a CVSS number. A Pre-Launch Check starts at $29, which is roughly the cost of the lunch you'd buy the security consultant you can't afford.

The rule of thumb: match the test to the blast radius. No users, no data → free scan. Login plus data → authenticated pentest before you onboard customer #1. Payments, PII at scale, or an enterprise buyer → a recurring engagement with continuous monitoring, because the bugs come back every time your AI assistant generates a new route.

The launch-week sequence that actually works

Run the free scan today. It's the cheapest signal you'll ever get. Scan your site free →
Fix every red header. Copy-paste configs exist for Next.js, Vercel, Nginx, and Cloudflare; this is an afternoon, not a sprint.
Do the 5-minute self-audit on your own auth: log in as two users and try to read each other's data. If you can, you have a BOLA and you are not ready to launch.
Get an authenticated test before user #1 if you store anyone's data. This is the step that separates the founders who make the news from the ones who don't.
Re-test on every major release. AI assistants regenerate the same bug classes each time you add a feature — security isn't one-and-done.

FAQ

Can't I just run an open-source scanner like OWASP ZAP myself?

You can, and you should learn it. But automated scanners — free or open-source — share the same blind spot: they don't understand your business logic or your data-ownership model, which is where the dangerous bugs live. They find the easy 30%. The 70% that ends startups needs a human who can log in as two users and chain three small flaws into a full data breach.

How much does a startup pentest actually cost in 2026?

Enterprise engagements run $10k–$30k and are scoped for codebases you don't have yet. Startup-focused testing is dramatically cheaper because the scope is tight: Sable's Pre-Launch Check is $29, Founder Shield $79, and Scale Secure $199. The point isn't "cheap" — it's right-sized. You're paying for the auth-flow and access-control findings, not a compliance binder.

I passed the free scan with an A. Am I safe?

You have good headers. That's the front door. It says nothing about whether a logged-in user can read another user's records, which is the bug that actually breaches startups. An A on the free scan and a BOLA in your API can coexist happily — we see it constantly.

Do I need this if I'm using a no-code platform?

Yes, and arguably more. No-code and AI-code platforms ship the same default-insecure patterns (RLS disabled, missing ownership checks) at scale, and the CVE-2025-48757 Lovable disclosure exposed 170+ generated apps — one with 13,000 user records — through exactly this class of bug.

The bottom line

A free scan is necessary and almost never sufficient. Run it first — it's free and it's honest about your external surface. But the moment your app has a login and a database, the decision is already made for you: the bugs that matter are invisible from the outside, and you need someone to log in and try the doors.

Start where it costs nothing. Run the free scan now, fix what it flags, and if you're storing anyone's data behind a login, book the $29 Pre-Launch Check before you onboard your first real user. Your future self — the one not writing a breach-disclosure email during launch week — will thank you.

June 2026 Patch Tuesday: An Actively-Exploited Chrome Zero-Day and a Wormable Windows RCE

Diego Diaz — Mon, 13 Jul 2026 20:17:01 +0000

Every month brings a Patch Tuesday, and most of them blur together. This one shouldn't. Two of the June 2026 fixes change the math on when you patch, not just whether you do.

The two that matter

CVE-2026-11645 is an out-of-bounds read and write in V8, the JavaScript and WebAssembly engine inside Google Chrome (CVSS 8.8). The detail that matters: it is already being exploited in the wild. Google shipped the fix on June 9. If your team or your users browse the web in Chrome — or any Chromium-based browser — this is a "today" problem, not a "this sprint" problem.

CVE-2026-45657 is a remote code execution flaw in the Windows Kernel, rated CVSS 9.8. It is unauthenticated and wormable: an attacker can run code at SYSTEM level with no user interaction, and a bug like that is the raw material for self-propagating malware. There is no confirmed exploitation yet — which is exactly the window you want to patch in.

What "actively exploited" actually changes

A normal CVSS-8 bug gives you a runway: triage, schedule, test, deploy over a couple of weeks. "Actively exploited" deletes that runway. It means a working exploit already exists, attackers are already using it, and every hour you wait is an hour you are knowingly exposed to a known technique. For CVE-2026-11645, the only correct patch timeline is "now."

The wormable kernel bug is the inverse risk: nobody is using it yet, but the moment a reliable exploit goes public, mass scanning starts within hours. The early-stage teams that get hit are the ones who told themselves "we'll get to it after the launch."

The patch-now checklist

Chrome / Chromium everywhere. Force-update Chrome on every machine, plus Edge, Brave, and anything Electron-based that bundles Chromium. Verify the version — don't assume auto-update ran.
Windows hosts, servers first. Apply the June cumulative update to internet-facing Windows servers before workstations. A wormable, unauthenticated kernel RCE is worst where it is reachable.
Inventory what you actually run. You can't patch the Chromium you forgot ships inside your desktop app or your CI runners.
Confirm, don't trust. "Patch deployed" and "patch applied and rebooted" are different states. Kernel patches usually need the reboot.

Where this fits

Patching your stack is step zero — the part you get no credit for until you skip it. What it does not cover is the code you shipped: the wildcard CORS, the secret in the repo, the auth check that isn't quite a check. That is the layer Sable scans for. But none of it matters if the box underneath is running a kernel an attacker can own for free. Patch first, then go find what your own app is leaking.

CVE-2026-42271: How a Popular AI Gateway Became an RCE Vector — And What to Audit in Your Stack

Diego Diaz — Mon, 13 Jul 2026 19:17:01 +0000

The Vulnerability

On May 8, 2026, BerriAI disclosed CVE-2026-42271, a command-injection flaw in LiteLLM — one of the most widely deployed open-source AI gateways. The vulnerability scored CVSS 8.8 and affects every release from version 1.74.2 to before 1.83.7. By June 9, CISA had added it to the Known Exploited Vulnerabilities (KEV) catalog, confirming active exploitation in the wild.

The root cause lives in two MCP-server preview endpoints: POST /mcp-rest/test/connection and POST /mcp-rest/test/tools/list. These endpoints accept a full server configuration in the request body — including the command, args, and env fields used by the stdio transport. When an authenticated user (or an attacker who chains this with the separate Starlette host-header bypass, CVE-2026-48710) sends a crafted payload, the injected command executes on the host with the privileges of the LiteLLM process. No sandboxing. No allowlist. Direct OS-level command execution.

Why This Matters for AI-Heavy Teams

LiteLLM has become the default glue layer for teams building AI-powered products. It normalizes API calls across OpenAI, Anthropic, Google, and dozens of open-weight models. If you've deployed an LLM feature in the last 12 months, there's a non-trivial chance LiteLLM sits somewhere in your stack — in front of your RAG pipeline, your agent framework, or your internal tool-calling layer.

That popularity is exactly what makes this an attack-surface problem, not just a single-CVE problem. The MCP (Model Context Protocol) integration that the vulnerable endpoints serve is the same pattern teams use to connect LLMs to external tools: databases, code execution sandboxes, file systems, APIs. Every MCP server you plug in via stdio transport carries its own command and args. If the gateway doesn't strictly validate those fields, the tool-calling feature becomes a command-injection feature.

The Hacker News reported that the flaw chains to unauthenticated RCE when combined with the Starlette host-header bypass — meaning an attacker who can reach the LiteLLM HTTP interface doesn't even need valid credentials.

What to Audit in Your AI Stack Right Now

If you run LiteLLM (or any AI gateway that proxies model calls and manages tool integrations), here's a concrete checklist:

Version check: Are you on LiteLLM ≥ 1.83.7? If not, upgrade immediately. This is a one-line fix in the stdio transport handler.
Endpoint exposure: Are /mcp-rest/test/connection and /mcp-rest/test/tools/list reachable from untrusted networks? If you don't use MCP server preview, disable or remove these endpoints entirely.
Authentication boundary: Even though CVE-2026-42271 requires authentication on its own, the Starlette bypass (CVE-2026-48710) removes that barrier. Treat the entire LiteLLM HTTP surface as public-facing until both are patched.
Process privileges: What user does the LiteLLM process run as? If it's root (common in containerized deployments that haven't been hardened), command injection means full container escape. Run as a non-root user with minimal capabilities.
MCP server inventory: List every MCP server your gateway is configured to call. Review the command and args for each. If any accept user-controlled input, that's a second-order injection risk.

The Bigger Pattern: AI Tooling Is Now Supply Chain

This isn't the first time an AI infrastructure component has turned into an attack vector, and it won't be the last. The Hugging Face ecosystem saw two critical CVEs in May 2026 (CVE-2026-0599 and CVE-2026-25874). The pattern is consistent: open-source AI tooling moves fast, security reviews lag, and the resulting components end up in production with the same trust level as a battle-tested web server — without the same hardening.

For early-stage teams especially, the lesson is not "don't use open-source AI tools." It's: every dependency in your AI pipeline needs the same scrutiny you'd give a database driver or an auth library. That means version pinning, CVE monitoring, least-privilege deployment, and network segmentation between your AI gateway and the rest of your infrastructure.

LiteLLM patched this in 1.83.7. The fix is already out. The question is whether your deployment is running it.

UNC6508: PRC Spies Exploit REDCap Servers to Infiltrate US Medical Research for 2 Years

Diego Diaz — Mon, 13 Jul 2026 18:17:01 +0000

What Happened

A threat actor tracked as UNC6508 — a China-nexus espionage group — infiltrated US medical research institutions and remained undetected inside their networks from September 2023 through at least November 2025, according to Google's Threat Intelligence team. The campaign targeted academic medical centers, private research organizations, military health institutions, and regulatory bodies across North America.

What makes this operation notable is not just its duration or targets, but the attacker's patience: UNC6508 spent nearly two years quietly embedded in research environments, exfiltrating sensitive data while blending into daily institutional workflows. The campaign was also covered by CyberSecurityNews and GBHackers, which independently confirmed the scope of the intrusion.

Technical Analysis

Initial Access via Legacy REDCap. UNC6508 gained initial access by exploiting legacy, unpatched versions of REDCap — an open-source electronic data capture platform widely used in clinical and academic research. Attackers specifically targeted institutions running legacy REDCap instances alongside current versions, allowing them to exploit known vulnerabilities in the older installation while remaining unnoticed.

Web Shell Deployment (help.php). After gaining access, the actors deployed a web shell named help.php on compromised REDCap servers, establishing persistent remote access to the underlying infrastructure.

INFINITERED Malware — a Three-Component Toolkit. UNC6508 deployed a custom malware family dubbed INFINITERED, consisting of three distinct components: a dropper that injects itself into upgrade packages to survive legitimate software updates, surviving patches that would normally eliminate compromise; a credential harvester that captures plaintext credentials from POST requests passing through the web application; and a C2 backdoor that receives commands via the REDCAP-TOKEN cookie, blending malicious communications with legitimate application traffic.

Novel Exfiltration: Abuse of Google Workspace Compliance Rules

Perhaps the most ingenious aspect of the campaign was the exfiltration method. UNC6508 created a mail compliance rule inside compromised institutions' Google Workspace environments — named "Patroit" — that used regex patterns to match intelligence-related keywords in emails. Any email matching these patterns (related to medical research, military health topics, etc.) was silently BCC-reenviated to a Gmail account controlled by the actor.

This approach provided several advantages for the attacker: encrypted email transit to Google's servers (no suspicious outbound connections), institutional trust in Google Workspace reducing suspicion, and a self-sustaining collection pipeline that operated automatically once the rule was in place.

Who's Affected

The campaign's targeting profile indicates strategic intelligence gathering rather than financial gain:

Academic medical centers — university-affiliated research hospitals across North America
Private medical research organizations — pharmaceutical and biotech research companies
Military health institutions — Department of Defense medical research facilities
Regulatory bodies — organizations involved in medical device and drug approval processes

The scope of compromised data — spanning clinical trial data, unpublished research findings, patient studies, and military health intelligence — represents a significant strategic intelligence haul for the PRC's biomedical and defense research sectors.

How to Protect Your Organization

1. Enforce 2SV on all admin accounts. Require two-step verification for all users with administrative privileges on REDCap servers and connected systems. Credential harvesting was a core component of this campaign, and 2SV directly mitigates stolen credentials.

2. Eliminate or update legacy REDCap instances. Audit your network for outdated REDCap deployments running alongside current versions. The coexistence of legacy and modern instances was the primary attack vector. Uninstall legacy versions entirely.

3. Audit compliance/mail forwarding rules. Review all content compliance and mail routing rules in Google Workspace (or equivalent platforms) for unauthorized rules with regex patterns or external forwarding addresses. Pay special attention to rules named generically or with automated-sounding labels.

4. Monitor REDCap file integrity. Deploy file integrity monitoring on REDCap web directories, specifically watching for unexpected PHP files like help.php. Google's Threat Intelligence team has published YARA rules and IOCs for INFINITERED.

5. Network segmentation for research infrastructure. Isolate REDCap servers from broader institutional research networks to limit lateral movement in case of compromise.

The Sable Angle

UNC6508's campaign against medical research is a textbook example of a persistent, low-and-slow intrusion designed to exfiltrate strategic intelligence over extended periods. The group's exploitation of legacy software alongside current versions, custom multi-component malware that survives updates, and abuse of trusted platforms like Google Workspace for exfiltration reflects a mature adversary operating with patience and operational security.

At Sable, our offensive security researchers regularly encounter similar persistence mechanisms and understand how threat actors exploit the gaps between legacy and modern infrastructure. Similar research-focused threats continue to emerge — from critical CVEs in research platforms to supply chain compromises targeting healthcare organizations.

Oracle E-Business Suite CVE‑2026‑46817: Critical Authentication Bypass in Oracle Payments

Diego Diaz — Mon, 13 Jul 2026 17:17:01 +0000

What Happened

On June 30, 2026, security outlets reported that CVE‑2026‑46817, a critical authentication‑bypass vulnerability affecting the Oracle Payments module of Oracle E‑Business Suite, is being actively exploited in the wild. The vulnerability carries a CVSS score of 9.8, indicating a severe impact. According to The Hacker News, attackers can reach the vulnerable component over the network without any valid credentials.

Technical Analysis

The flaw resides in the Oracle Payments component of Oracle E‑Business Suite. It is classified as an improper privilege management or authentication bypass issue. Unauthenticated attackers who can reach the affected HTTP endpoints can gain privileged access to the Oracle Payments system, potentially taking full control of the ERP module. The vulnerability affects versions 12.2.3 through 12.2.15 of the suite. No public proof‑of‑concept or detailed exploit mechanics have been disclosed; the specific technical details of the attack vector remain undisclosed, as highlighted by both Security Affairs.

Who’s Affected

Enterprises running the affected Oracle Payments module across a broad range of industries are at risk. While exact numbers of impacted installations are not publicly known, the vulnerability’s severity and the fact that it is being actively exploited suggest a wide exposure. The recent activity mirrors previous attacks on Oracle ERP products, such as the exploitation of CVE‑2026‑35273 in Oracle PeopleSoft PeopleTools by the ShinyHunters group earlier in 2026.

How to Protect Yourself

Apply the latest Oracle Critical Patch Update (CPU). Oracle released a patch for CVE‑2026‑46817 in its most recent Critical Patch Update of the previous month. Administrators should verify the patch is applied and restart the affected services.
Restrict network access. Limit exposure of the Oracle Payments web endpoints to trusted internal networks or VPNs. Use firewalls or Web Application Firewalls (WAF) to block unauthenticated traffic.
Monitor for suspicious activity. Review web server logs for unusual requests to Oracle Payments URLs and set up IDS/IPS signatures that can detect attempts to exploit authentication bypasses.
Conduct regular security assessments. Validate that all Oracle E‑Business Suite instances are patched and not exposed to the internet without proper controls.

The Sable Angle

Sable helps organizations identify exposed Oracle E‑Business Suite instances and verify that the required CPU patches are applied. Our assessments focus on discovering internet‑facing ERP deployments, testing for unauthenticated access, and providing remediation guidance. By partnering with Sable, you can gain confidence that your Oracle Payments environment is not susceptible to the current exploitation trend. Learn more about our services at Sable pricing.

Microsoft SharePoint Server Remote Code Execution (CVE‑2026‑45659) Actively Exploited

Diego Diaz — Mon, 13 Jul 2026 16:21:59 +0000

What Happened

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) added a high‑severity vulnerability to its Known Exploited Vulnerabilities (KEV) catalog on July 2, 2026. The flaw, tracked as CVE‑2026‑45659 with a CVSS score of 8.8, affects Microsoft SharePoint Server Subscription Edition, SharePoint Server 2019, and SharePoint Enterprise Server 2016. It is a deserialization‑of‑untrusted‑data bug that allows an authenticated attacker with just Site Member permissions to execute arbitrary code over the network.

Technical Analysis

Deserialization vulnerabilities arise when an application processes serialized objects without proper validation. In SharePoint, the flaw resides in the handling of certain object streams used by the server’s backend services. When a malicious payload is supplied, the server deserializes it and runs attacker‑controlled code. Because the vulnerability is network‑based, exploitation requires only a valid SharePoint credential – no administrative rights are needed. Microsoft’s advisory notes that the attack complexity is low (AC:L) and the required privileges are minimal (PR:L). The bug was addressed in May 2026; Microsoft released patches for the affected versions – SharePoint Server Subscription Edition, SharePoint Server 2019, and SharePoint Enterprise Server 2016 – [Microsoft patch details]. However, the vulnerability was inadvertently omitted from the May security update announcement, leaving many systems exposed.

Who’s Affected

Any organization running on‑premises SharePoint Server versions listed above is at risk. Shadowserver reports that over 10,000 SharePoint instances are publicly reachable on the internet, many of which likely host outdated software. Federal civilian agencies have been specifically warned to remediate by July 4, 2026, but the exposure spans private enterprises, universities, and government contractors worldwide. Attackers can leverage the foothold to move laterally across internal networks, exfiltrate sensitive documents, or deploy ransomware payloads. The active exploitation signal from CISA suggests that threat actors are already weaponising the flaw in the wild.

How to Protect Yourself

Apply Microsoft’s May 2026 patches immediately on all SharePoint Server instances. Verify the installed versions match the patched releases.
Enable multi‑factor authentication (MFA) for all SharePoint accounts. Reducing the pool of valid credentials mitigates the low‑privilege authentication vector.
Conduct an internet‑exposure scan (e.g., using Shodan or Shadowserver data) to identify any externally accessible SharePoint servers. Block inbound traffic at the perimeter where feasible.
Review audit logs for unusual access patterns, especially login events from non‑corporate IP ranges or repeated failed attempts.
Implement strict least‑privilege assignments: ensure users only have the permissions required for their role, removing unnecessary Site Member rights.

The Sable Angle

At Sable we routinely audit on‑premises collaboration platforms for exactly these kinds of deserialization flaws. Our recent research into supply‑chain attacks highlighted how a single unpatched service can become the launchpad for nation‑state actors [OpenClaw research]. By combining automated scanning with threat‑intelligence feeds, we can surface vulnerable SharePoint installations before attackers do.

If you need a deeper dive into how the vulnerability interacts with custom SharePoint web parts, check out our technical brief on the exploitation pathway. Our team stands ready to assist with rapid patch validation, forensic triage, and hardening recommendations to keep your data safe.

Ubiquiti UniFi Critical Flaws Exposed: CVE-2026-50746 and Companion Vulnerabilities

Diego Diaz — Mon, 13 Jul 2026 16:17:01 +0000

What Happened

Ubiquiti disclosed a series of high‑severity vulnerabilities across its UniFi product line on July 8, 2026. The most dangerous, CVE‑2026‑50746, received a CVSS 10.0 rating – the highest possible score – because it can be exploited remotely without authentication, using an Improper Access Control flaw in the UniFi Connect application. An attacker who can reach the management interface can inject arbitrary operating‑system commands and take complete control of the host.

In addition to CVE‑2026‑50746, Ubiquiti patched six other critical issues: CVE‑2026‑50747 (SQL injection in UniFi Talk), CVE‑2026‑50748 (command injection in UniFi Access), CVE‑2026‑54400 (privilege escalation in UniFi Access), CVE‑2026‑54402 (command injection in UniFi OS), CVE‑2026‑55115 (SSRF in UniFi Protect) and CVE‑2026‑55116 (unauthorized changes in UniFi OS). All were fixed in the same security release.1 2

Technical Details

The CVE‑2026‑50746 vulnerability resides in UniFi Connect versions 3.4.16 and earlier. The component fails to verify the caller’s privileges before passing a crafted request to a system‑level command interpreter. As a result, a network‑adjacent attacker can send a specially‑crafted HTTP request that triggers command execution on the underlying Linux host. Because UniFi Connect often runs with root privileges to manage device provisioning, the impact is full system compromise.

Other flaws follow a similar pattern of insufficient input validation. CVE‑2026‑50747 is an authenticated SQL injection that allows an attacker with low‑privilege network access to escalate to admin on UniFi Talk. CVE‑2026‑50748 and CVE‑2026‑54402 are both command‑injection bugs in UniFi Access and UniFi OS respectively, reachable via malformed REST calls. CVE‑2026‑55115 is a server‑side request forgery (SSRF) in UniFi Protect that lets a low‑privileged attacker trick the backend into contacting internal services, leading to privilege escalation. CVE‑2026‑55116 is an access‑control weakness that permits unauthorized configuration changes in UniFi OS.

Impact

Threat intelligence firms estimate that over 100 000 UniFi OS instances are exposed to the public internet (TechTimes). If any of these devices run vulnerable versions, they become prime recruitment targets for botnets – similar to the “MooBot” botnet that leveraged compromised Ubiquiti EdgeOS routers in 2024. Successful exploitation grants attackers arbitrary code execution, enabling data exfiltration, lateral movement, or the deployment of ransomware. The CVE‑2026‑50746 flaw alone is powerful enough for nation‑state actors to gain footholds in critical infrastructure that relies on UniFi for building automation, lighting, or EV‑charging management.

Mitigation

Ubiquiti’s advisory urges immediate updates:

Upgrade UniFi Connect to version 3.4.20 or later.
Upgrade UniFi Talk to 5.2.2, UniFi Access to 4.2.29, UniFi OS Server to 5.1.19, and UniFi Protect to 7.1.83.
Verify that all UniFi devices are no longer reachable from the public internet unless explicitly required. Use firewall rules or VPNs to restrict management traffic.
Run vulnerability scans (e.g., using Censys or Shodan) to identify any lingering vulnerable instances.
Monitor logs for unexpected command‑execution patterns or outbound requests indicating SSRF attempts.

Organizations should also apply the same hardening steps they use for other network‑exposed management consoles: enforce strong authentication, enable multi‑factor authentication, and segment management networks.

For additional guidance, see Ubiquiti’s official security bulletin and the detailed analysis from BleepingComputer (source).

Critical XSS Flaw in Zimbra Classic Web Client Enables Arbitrary Code Execution

Diego Diaz — Mon, 13 Jul 2026 16:04:15 +0000

What Happened

Zimbra announced a critical stored cross‑site scripting (XSS) vulnerability in its Classic Web Client that allows specially crafted emails to execute arbitrary JavaScript in a user’s browser. The flaw can expose mailbox contents, session data, and account settings if an email is opened. The issue has not yet been assigned a CVE identifier, but Zimbra confirmed that the vulnerability enables arbitrary code execution The Hacker News.

Technical Analysis

The XSS flaw resides in the Classic Web Client’s handling of email bodies. When an email contains malicious script tags, the client fails to properly sanitize or escape the input, storing the payload in the server‑side database. Upon retrieval, the script runs in the context of the logged‑in user’s session, granting access to cookies and session tokens. The vulnerability was discovered by Google’s Threat Analysis Group and reported to Zimbra, which subsequently released version 10.1.19 to remediate the issue BleepingComputer and SC Media.

Who’s Affected

The flaw impacts all deployments of Zimbra Collaboration Suite that still use the Classic Web Client, which is common in large enterprises and government agencies due to its lower resource consumption. Zimbra estimates millions of installations worldwide, with a significant portion of the user base relying on the Classic UI for email access. Because the vulnerability is stored, any organization that receives a malicious email can become compromised without user interaction beyond opening the message.

How to Protect Yourself

Immediately upgrade to Zimbra Collaboration Suite version 10.1.19, which includes the XSS fix.
If you cannot upgrade immediately, disable the Classic Web Client and force users to the modern UI to mitigate the attack surface.
Apply strict email filtering to block suspicious attachments and HTML content containing script tags.
Enforce multi‑factor authentication (MFA) for all mailbox logins to limit the impact of stolen session tokens.
Monitor server logs for unusual JavaScript execution patterns or unexpected outbound requests from the web client.

The Sable Angle

At Sable we routinely audit email collaboration platforms for hidden attack vectors. Our research team has built automated detection scripts that surface stored XSS payloads across large mailboxes, helping clients pre‑emptively identify vulnerable messages before they reach end users. Learn more about our offensive security services on the Research page and see how we helped secure similar high‑profile email systems in the past.

References

The Hacker News – Critical Zimbra Flaw
BleepingComputer – Zimbra XSS Patch
SC Media – Zimbra XSS Advisory