FullHunt Blog

wp2shell (CVE-2026-63030): Pre-Auth RCE Chain in WordPress Core

2026-07-17T00:00:00-05:00

CVE-2026-63030 is a pre-authentication remote code execution vulnerability in WordPress Core affecting versions 6.9.0 through 7.0.1. A single anonymous POST to the REST API batch endpoint reaches a SQL injection that leads to direct access to the WordPress and can be escalated to a pre-auth RCE.

WordPress patched it in 6.9.5 and 7.0.2, touching three files and sixteen lines. This post covers what broke, why the bugs connect, and what teams running WordPress need to do.

Background

The patch diff between 7.0.1 and 7.0.2 is three files. The batch REST API endpoint has been present since WordPress 5.6. The bugs were introduced when the endpoint landed in the 6.9 development branch, roughly a year before disclosure.

Affected files:

src/wp-includes/rest-api/class-wp-rest-server.php
src/wp-includes/class-wp-query.php
src/wp-includes/rest-api.php

Identify wp2shell Exposure with FullHunt

FullHunt fingerprints web technologies across every host it discovers, including WordPress. Look up tag:wordpress in the FullHunt Console to list every WordPress asset already mapped across your attack surface, then cross-reference the results against the affected range (6.9.0 through 7.0.1) while you patch.

FullHunt Enterprise customers get continuous monitoring, so newly discovered or newly exposed WordPress assets are flagged automatically as they appear on the perimeter, without re-running the search by hand.

We’re also open-sourcing wp2shell-scan, a scanner for CVE-2026-63030. It ships two non-destructive detection modes, time-based and error-based, for checking your own infrastructure at scale.

The vulnerability

Bug 1: Array index desynchronisation in `serve_batch_request_v1`

The batch endpoint at /wp-json/batch/v1 (also reachable via ?rest_route=/batch/v1) accepts a single POST containing multiple sub-requests. Processing happens in two passes.

In the first pass, WordPress parses each sub-request URL, matches it to a route handler, validates parameters, and sanitizes them. Results go into two arrays that are supposed to stay in lockstep:

$matches[$n] – the matched route and handler tuple
$validation[$n] – true if everything passed, or a WP_Error describing what failed

In the second pass, WordPress iterates $requests by integer index $i and cross-references $matches[$i] with $validation[$i] to decide whether to execute the handler or return an error.

The vulnerable code from 7.0.1:

$matches    = array();
$validation = array();
$has_error  = false;

foreach ( $requests as $single_request ) {

    // A request that couldn't be parsed becomes a WP_Error
    if ( is_wp_error( $single_request ) ) {
        $has_error    = true;
        $validation[] = $single_request;   // pushed to $validation
        continue;                           // $matches NOT updated -- the bug
    }

    $match     = $this->match_request_to_handler( $single_request );
    $matches[] = $match;

    // ... allow_batch check, has_valid_params(), sanitize_params() ...

    if ( $error ) {
        $has_error    = true;
        $validation[] = $error;
    } else {
        $validation[] = true;
    }
}

When a sub-request is a WP_Error (any time the URL can’t be parsed), the code pushes one entry into $validation and zero into $matches. One WP_Error is enough to permanently shift every subsequent $matches[$i] one slot ahead of where $validation[$i] expects it.

That misalignment shows up in the execution pass:

foreach ( $requests as $i => $single_request ) {

    if ( is_wp_error( $single_request ) ) {
        // WP_Error sub-requests get handled here and skipped
        $responses[] = $this->envelope_response(
            $this->error_to_response( $single_request ), false
        )->get_data();
        continue;
    }

    $match = $matches[ $i ];         // WRONG index due to the shift
    $error = null;

    if ( is_wp_error( $validation[ $i ] ) ) {   // WRONG validation result
        $error = $validation[ $i ];
    }

    $result = $this->respond_to_request( $single_request, $route, $handler, $error );
}

With three sub-requests (one benign, one WP_Error, one malicious) the array state after the validation pass looks like this:

$requests:   [ benign_req,  err_req,    malicious_req  ]
             -----------------------------------------
$matches:    [ benign_hdl,              malicious_hdl  ]  indices 0, 1
$validation: [ true,        WP_Error,   WP_Error       ]  indices 0, 1, 2
                            ^-- shift applied here -----^

In the execution pass, $i = 2 (malicious request slot): $matches[2] is the malicious handler but $validation[2] is a WP_Error, so the error gate fires. But at $i = 1 (benign request slot): $matches[1] is now the malicious handler and $validation[1] is the WP_Error from the unparseable URL, not from any check on the malicious request.

The attacker controls sub-request ordering. By placing the WP_Error at the right position, they align the malicious handler with a true validation result from a different request’s clean pass, bypassing:

has_valid_params() – REST schema type checking (e.g., author_exclude must be integer[])
sanitize_params() – per-element sanitisation (e.g., absint())
The allow_batch route check

The fix was one added line:

  if ( is_wp_error( $single_request ) ) {
      $has_error    = true;
+     $matches[]    = $single_request;   // keep arrays in sync
      $validation[] = $single_request;
      continue;
  }

Both arrays now receive an entry for every input. In the execution pass, $matches[$i] for a WP_Error slot is itself a WP_Error, caught by the existing is_wp_error($match) check before any handler runs.

Bug 2: Re-entrancy in `serve_request` and `rest_api_loaded`

WordPress loads the REST API through rest_api_loaded(), hooked to parse_request. It reads $wp->query_vars['rest_route'], then calls $wp_rest_server->serve_request($path). This entry point is designed to run once per HTTP request.

The batch controller dispatches sub-requests by calling dispatch() (the internal method), not serve_request(). That’s the correct separation. But nothing in 7.0.1 prevented a hook or callback triggered during batch dispatch from calling rest_api_loaded() again. If any code path during dispatch caused WordPress to re-run the main query loop with rest_route in the environment, a fresh serve_request() would start. That nested cycle has no awareness of the outer batch context, no batch permission checks, and no knowledge of the sub-request currently being dispatched.

This path is only reachable when a persistent object cache is not in use. With Redis or Memcached, early cache hits short-circuit WP_Query execution, collapsing the hook surface that enables re-entrancy. Without a cache (the default for a stock WordPress install), the full get_posts() path runs every time, firing all its hooks.

The fix added an is_dispatching() guard to both entry points.

In serve_request():

  public function serve_request( $path = null ) {
+     if ( $this->is_dispatching() ) {
+         return false;
+     }
+
      global $current_user;
      // ...

In rest_api_loaded():

+ if ( isset( $GLOBALS['wp_rest_server'] )
+     && $GLOBALS['wp_rest_server'] instanceof WP_REST_Server
+     && $GLOBALS['wp_rest_server']->is_dispatching()
+ ) {
+     return;
+ }

is_dispatching() reads a request stack maintained inside dispatch():

protected $dispatching_requests = array();

public function is_dispatching() {
    return (bool) $this->dispatching_requests;
}

While any dispatch is in flight, the stack is non-empty. Any attempt to call serve_request() from a nested hook returns immediately.

Bug 3: SQL injection in `WP_Query` via string `author__not_in`

The REST API Posts endpoint exposes an author_exclude parameter that maps directly to author__not_in in WP_Query. The REST layer validates author_exclude as type: array, items: { type: integer } and sanitises each element with absint(). Bug 1 bypasses that layer entirely.

What WP_Query::get_posts() does with author__not_in in 7.0.1:

if ( ! empty( $query_vars['author__not_in'] ) ) {

    if ( is_array( $query_vars['author__not_in'] ) ) {
        // Only sanitised when it's an array:
        $query_vars['author__not_in'] = array_unique(
            array_map( 'absint', $query_vars['author__not_in'] )
        );
        sort( $query_vars['author__not_in'] );
    }

    // Always runs, even when the value is a raw string:
    $author__not_in  = implode( ',', (array) $query_vars['author__not_in'] );
    $where          .= " AND {$wpdb->posts}.post_author NOT IN ($author__not_in) ";
}

The is_array() check controls sanitisation but not execution. When the value is a string:

is_array("payload") returns false, sanitisation skipped entirely
(array) "payload" produces ["payload"] – PHP’s cast puts the string in a single-element array
implode(',', ["payload"]) returns "payload"
The string lands verbatim in the SQL query

The fix replaces the entire block with wp_parse_id_list(), which is safe regardless of input type:

- if ( is_array( $query_vars['author__not_in'] ) ) {
-     $query_vars['author__not_in'] = array_unique( array_map( 'absint', $query_vars['author__not_in'] ) );
-     sort( $query_vars['author__not_in'] );
- }
- $author__not_in  = implode( ',', (array) $query_vars['author__not_in'] );
- $where          .= " AND {$wpdb->posts}.post_author NOT IN ($author__not_in) ";
+ $author__not_in_id_list = wp_parse_id_list( $query_vars['author__not_in'] );
+ if ( count( $author__not_in_id_list ) > 0 ) {
+     sort( $author__not_in_id_list );
+     $where .= sprintf(
+         " AND {$wpdb->posts}.post_author NOT IN (%s) ",
+         implode( ',', $author__not_in_id_list )
+     );
+     $query_vars['author__not_in'] = $author__not_in_id_list;
+ }

wp_parse_id_list() handles both strings and arrays, and runs absint() on every element without exception:

function wp_parse_id_list( $input_list ) {
    $input_list = wp_parse_list( $input_list );             // splits a string into array if needed
    return array_unique( array_map( 'absint', $input_list ) ); // absint() every element
}

The attack chain

An unauthenticated attacker sends a single POST to /wp-json/batch/v1:

POST /wp-json/batch/v1
Content-Type: application/json

{
  "validation": "normal",
  "requests": [
    {
      "path": "/wp/v2/posts",
      "method": "GET"
    },
    {
      "path": "://invalid-url",
      "method": "GET"
    },
    {
      "path": "/wp/v2/posts",
      "method": "GET",
      "body": {
        "author_exclude": "<injection payload>"
      }
    }
  ]
}

What happens:

Sub-request 0 (benign GET /wp/v2/posts) passes validation. $matches[0] is the posts handler, $validation[0] is true.
Sub-request 1 (bad URL) becomes a WP_Error. $validation[1] gets the error. $matches skips an index.
Sub-request 2 (malicious author_exclude string) fails schema validation at the REST layer. $validation[2] is a WP_Error. But $matches[1] is now the posts handler pointed at sub-request 2’s body.

In the execution pass, the index shift means the posts handler runs with sub-request 2’s payload but sub-request 1’s (empty) validation result. Schema checking is bypassed. The raw string reaches WP_Query::get_posts().

The re-entrancy path in Bug 2 provides an alternative route. The sub-request dispatch triggers rest_api_loaded() again through a hook, starting a fresh serve_request(). That cycle processes the malicious author_exclude as a top-level request, also bypassing REST layer validation. On a site without Redis or Memcached, this path is independently reachable.

Either way, get_posts() receives a string author__not_in. The is_array() guard returns false, sanitisation skips, and the value interpolates directly into:

AND wp_posts.post_author NOT IN (<your_string_here>)

What determines whether SQLi becomes RCE

The injection gives read access to the full database. Escalation depends on the MySQL configuration:

Condition	Impact
MySQL `FILE` privilege granted to the WP DB user	Direct file write via `INTO OUTFILE` is possible
`secure_file_priv` is empty or points to webroot	File can land in a web-accessible path
Webroot writable by the MySQL process	Shell is reachable immediately
No `FILE` privilege	RCE still possible via `UPDATE wp_options` (auto-loaded PHP eval paths, malicious plugin data)

Stock shared hosting and self-managed single-server WordPress installs frequently have FILE privilege enabled and the webroot writable by the database process. Managed cloud deployments with a separated DB and locked-down MySQL user are harder to escalate beyond data exfiltration, but the SQLi itself still works.

Why these bugs existed

The parallel array bug is the simplest. serve_batch_request_v1 assumes $matches and $validation stay the same length. They grow through []= assignments in different branches of the same loop, with nothing enforcing that both arrays are updated together. Whoever added the WP_Error branch would focus on $validation (where the error just landed) and miss that $matches needed an entry too. Using two parallel arrays instead of a single struct per sub-request is what made this possible to miss in the first place.

WP_Query is a different kind of problem. It was written expecting author__not_in to always be an integer array, because historically callers passed integer arrays. The is_array() check ran absint() per element. The else branch was not written with user-controlled strings in mind – (array) was a convenience cast before implode, not a trust boundary. When the REST API started accepting JSON bodies, that assumption quietly broke. Nothing in WP_Query was updated.

The re-entrancy bug is the one that would be hardest to catch in review. The batch controller correctly calls dispatch() (internal) rather than serve_request() (external). That’s the right separation. But WordPress’s hook system lets any action or filter run arbitrary code during execution, including inside get_posts(). rest_api_loaded() had no guard against being invoked from within an active dispatch, and for a year nothing triggered that path.

Affected versions

Branch	Affected	Fixed
Before 6.9	Not affected (batch endpoint absent)
6.8	6.8.0 through 6.8.5 (SQLi only, no full chain)	6.8.6
6.9	6.9.0 through 6.9.4	6.9.5
7.0	7.0.0 through 7.0.1	7.0.2
7.1	7.1-beta1	7.1-beta2

WordPress auto-updates affected installs where automatic updates are enabled. Verify the version manually. Auto-update completion is not guaranteed on every host configuration.

Mitigation

Patch first. Update to 6.9.5, 7.0.2, or 7.1-beta2. That’s the only complete fix.

If patching isn’t immediately possible, block the batch endpoint at the WAF or load balancer:

Block requests where http.request.uri.path contains /wp-json/batch/v1
Block requests where url_decode(http.request.uri.query) contains rest_route=/batch/v1

The url_decode() step is necessary. Cloudflare’s URL normalization preserves reserved %2F escapes, so a raw string match on rest_route=/batch/v1 misses ?rest_route=%2Fbatch%2Fv1. Decoding before matching catches both forms.

At the database layer:

Confirm the WordPress DB user does not have FILE privilege
Confirm secure_file_priv points to a non-webroot path in my.cnf

These don’t prevent the SQLi but remove the direct file-write escalation path.

Indicators of compromise

If investigating whether a host was hit before patching, check:

Unexpected PHP files in the webroot, especially recently created ones
WordPress error logs with malformed batch API requests (entries containing :// in sub-request paths)
MySQL general query log entries containing INTO OUTFILE or LOAD DATA
New rows in wp_options with autoload = yes and suspicious serialized PHP content
Web access logs showing POST /wp-json/batch/v1 or GET /?rest_route=%2Fbatch%2Fv1 from a single IP in a short window, followed by a request to a new PHP file

References

Are you an enterprise looking to enhance your security posture with advanced attack surface management, vulnerability intelligence, and threat detection? Contact us at team@fullhunt.io or visit our contact page to learn how FullHunt can help secure your organization.

Discover unknown assets today and protect your organization

Best regards,
Mazin Ahmed
The FullHunt Team

#JoinTheHunt

FullHunt Releases Agentic AI for Attack Surface Intelligence

2025-10-16T00:00:00-05:00

FullHunt launches Agentic AI capabilities for Attack Surface Mapping, Internet-Wide Assets Discovery, and Vulnerability Management to enable security teams to build Agentic AI workflows for securing external attack surfaces.

FullHunt Releases Agentic AI for Attack Surface Intelligence

We’re launching FullHunt Agentic AI, powered by the Model Context Protocol (MCP). Instead of writing scripts, clicking through dashboard tabs, or building custom integrations, you can request for a full attack surface analysis to any organization on the Internet, instantly.

This is a major upgrade to today’s security testing workflows. With simple prompts, you can enumerate all internet-facing assets for “acme.com,” flag exposed admin panels, find vulnerable assets via FullHunt Vulnerability Intelligence, and surface exposures.

In recent months, we focused on improving the user experience and exposing all of FullHunt’s APIs and capabilities. We’re excited to share this release.

Ask in Simple Words

“Investigate acme.com and flag exposed admin panels.”

The agent discovers subdomains, inspects hosts, looks for admin indicators, correlates with vulnerability data, and returns an actionable report.

“Find exploits for CVE-2025-1234 and check our exposure.”

It pulls exploits and PoCs, checks your assets, references EPSS/CISA KEV, and prioritizes remediation.

“Is IP 8.8.8.8 malicious? Which domains point to it?”

It runs IP reputation, Tor checks, reverse/passive DNS, and builds a concise threat profile.

Behind the scenes, many actions run inside FullHunt to keep this simple. In fact, it takes 10 seconds to build a full analysis on your attack surface.

40+ AI-Accessible Security Tools

The FullHunt MCP Server exposes 40+ production tools the agent can call:

Domain & Host Intelligence: domain/subdomain discovery, host tech, ASN/IP ranges, DNS & passive DNS.

Vulnerability Intelligence: CVE + EPSS, exploit/PoC lookups, CISA KEV, auto-correlation.

Attack Surface Management: on-demand scans (domains/IPs/CIDRs), continuous discovery, tech stack ID, cert monitoring.

Threat Intelligence: IP reputation/geo, Tor exit detection, passive DNS, domain collections.

Dark Web Monitoring: credential/breach intel, phishing and typosquat detection.

Enterprise: orgs & tenants, real-time alerts, asset inventory, custom entity monitoring.

Available on FullHunt Professional Accounts!

FullHunt Agentic AI is available for both professional and enterprise accounts. You can sign up for a professional plan instantly at fullhunt.io/signup.

Integration is Simple

FullHunt Agentic AI is built on the Model Context Protocol (MCP), an open standard pioneered by Anthropic for AI tool integration. The following Claude Desktop configuration can be used directly to integrate with FullHunt Agentic AI.

{
  "mcpServers": {
    "fullhunt": {
      "transport": "http",
      "url": "https://fullhunt.io/api/v1/mcp",
      "headers": {
        "X-API-KEY": "${env:FULLHUNT_API_KEY}"
      }
    }
  }
}

Enterprise customers get dedicated Agentic AI tenants.

Get started and contact us for support and integrations.

Are you an enterprise looking to enhance your security posture with AI-powered attack surface management, vulnerability intelligence, and threat detection? Contact us at team@fullhunt.io

Discover unknown assets today and protect your organization

Best regards,
Mazin Ahmed
Founder, FullHunt

#JoinTheHunt

FullHunt 💜 Open-Source: 39,408 Exploits from 0day.today is Back Online

2025-09-28T00:00:00-05:00

FullHunt is rolling out the complete 0day.today archive, featuring 39,408 exploits and nearly three decades of vulnerability research.

Open-Source Release: 0day.today Exploits Archive

FullHunt is rolling out the complete 0day.today archive, featuring 39,408 exploits and vulnerability research from almost 30 years of security work.

FullHunt launched 0day-archive.fullhunt.io to preserve the legacy of the 0day.today, 1337day, and milw0rm exploits databases.

The database contains 39,408 exploits from 1996–2025, preserving decades of discoveries by the security community.

What is the 0day.today Archive?

The 0day.today Archive recreates and preserves the classic 0day.today database, part of the Milw0rm legacy.

Since the 2000s, Milw0rm was a key resource for security researchers, penetration testers, and cybersecurity professionals worldwide, hosting a vast collection of exploits, proof-of-concepts, and vulnerability research.

Credits

Thanks to Jacob Baines for cloning and open-sourcing the 0day.today content on GitHub. FullHunt analyzed the data against various open-source clones and restored the website thanks to this contribution.

Getting Started

Visit 0day-archive.fullhunt.io to explore the complete archive.

Visit the archive: 0day-archive.fullhunt.io
GitHub repository: github.com/fullhunt/0day-today-archive

Discover unknown assets today and protect your organization

Best Regards,
Mazin Ahmed
Founder, FullHunt

#JoinTheHunt

Introducing FullHunt Vulnerability Intelligence

2025-09-18T00:00:00-05:00

FullHunt launches Vulnerability Intelligence - a comprehensive solution to understand and contextualize vulnerabilities at scale with enriched data and public exploits.

Introducing FullHunt Vulnerability Intelligence

When I started FullHunt, one of my goals has been to build a centralized ecosystem to understand and secure Internet-facing assets. The journey continues, and today I’m excited to launch an innovation from the FullHunt team: FullHunt Vulnerability Intelligence, and it’s now available to all FullHunt customers and community members.

What is FullHunt Vulnerability Intelligence?

FullHunt Vulnerability Intelligence is a comprehensive solution to understand and contextualize vulnerabilities at scale. FullHunt aggregates vulnerability data from various sources, and continuously looks for new exploits, proof of concepts, research papers, and enriches vulnerabilities with various FullHunt sources to build enriched vulnerability data.

FullHunt provides its Vulnerability Intelligence through the FullHunt console and APIs. You can also integrate it into your own tools, and test it with your free community account.

Key Features

With FullHunt Vulnerability Intelligence, you can:

Find exploits automatically for any given CVE
Get enriched details about exploitability updated with EPSS scoring
Access enrichments whenever vulnerabilities are commonly exploited through CISA KEV feeds

Available Through Console and APIs

FullHunt provides its Vulnerability Intelligence through multiple channels:

FullHunt Console: Access vulnerability intelligence directly through our web interface
APIs: Integrate vulnerability data into your existing security tools and workflows
Free Community Access: Test and explore the capabilities with your free community account

Continuous Security Innovation

We’re continuously building security software, and we’re making it available through our APIs. If you’re a security researcher, consultant, engineer, or anyone interested in security automation, you should check out the FullHunt API!

Are you an enterprise looking to solve Attack Surface Discovery, continuous monitoring, security scanning, and custom-developed tools and APIs? Please reach out to us at team@fullhunt.io or fill the out form on our contact page, and we will be happy to solve your challenges.

Discover unknown assets today and protect your organization

Best Regards,
Mazin Ahmed
Founder, FullHunt

#JoinTheHunt

Introducing FullHunt’s OEM Intelligence API for Security Platforms

2025-05-06T00:00:00-05:00

FullHunt released the OEM Intelligence API to enable seamless integration of attack surface intelligence into security platforms.

Introducing FullHunt’s OEM Intelligence API for Security Platforms

Today, we’re excited to announce the launch of FullHunt’s OEM Intelligence API, a new offering that allows security platforms and service providers to integrate FullHunt’s dark web monitoring and attack surface intelligence directly into their own products. This initiative is a game-changer for MSSPs, XDR and SIEM vendors, GRC platforms, and any enterprise security solution provider looking to augment their platform with rich security insights. With the OEM API, FullHunt essentially becomes your “intel engine” in the backend – powering your features with our data, FullHunt is rolling out OEM APIs to let you “integrate FullHunt’s discovery and vulnerability scanning into your own security platform,” offering your users a seamless extension of FullHunt’s attack surface management (ASM) datasets within your product.

What Does the OEM Intelligence API Include?

The OEM Intelligence API encompasses three primary endpoints, each corresponding to a core FullHunt intelligence service:

Attack Surface Search API

This endpoint allows you to query FullHunt’s external asset database for information on a given target domain. Essentially, it performs an attack surface enumeration – returning data on all subdomains and hosts related to the domain, along with metadata about each host (open ports, running services, technologies, SSL certificates, and more). Think of it as instantly running an internet-wide scan for your target, but with one API call. For example, if integrated into a security platform, a user who enters their company domain on your interface could receive within seconds a full list of discovered assets: vpn.acme.com, mail.acme.com, dev.acme.com, etc., each with IP addresses and details like “this host is running nginx on port 443 with a certificate for *.acme.com, and has an HTTP title ‘Acme Corp – Login’”. FullHunt’s scanning engine constantly discovers and refreshes this data, so your platform leverages a living, up-to-date inventory. Use cases include continuous attack surface monitoring (alert when a new subdomain appears or an open port is found), asset inventory for IT/security teams, or even feeding this info into a vulnerability scanner or SOC automation. The key value is that your users gain immediate visibility into their external footprint without running separate scans – it’s all integrated into your product workflow. You can also automate actions like creating tickets for newly exposed services or unsafe configurations detected via the data.

Organizations Search API

This endpoint provides organization intelligence, essentially a knowledge base of company information and security-relevant facts. When integrated, it enables your platform to retrieve a profile of any organization by name or domain. The response includes company details (official name, industry, size, headquarters) and importantly, known security incidents (breaches) and related entities (subsidiaries, parent company, etc.). For a practical example, imagine a third-party risk management module in your GRC software: when onboarding a new vendor, you could call this API to automatically fill in the vendor’s profile and flag if that company has a history of breaches or cybersecurity incidents. Similarly, a threat intelligence platform might use it to enrich context around targets or adversaries (e.g. pulling up info on a company that a threat actor claims to have breached). All of this with one query. It adds a layer of situational awareness that can greatly aid decision-making in security operations and risk assessment. From a technical standpoint, this API is straightforward to use and the returned JSON is well-structured, so parsing out fields like estimated_employee_count or notable_breaches is trivial.

Dark Web Search API

This endpoint gives your platform direct access to FullHunt’s dark web and breach intelligence database. You can search for compromised credentials and sensitive data exposures using a variety of identifiers. For example, you can query by an email address to find if that email (or accounts associated with it) have appeared in any data breaches, or search by a company domain to retrieve all credential leaks related to that organization. FullHunt’s dataset covers credentials and personal info leaked on underground forums, paste sites, dark web marketplaces, and public breach dumps. The API returns detailed records including exposed usernames, passwords (hashed or plaintext), names, contact info, and the source of the breach. By integrating this, an MSSP or XDR platform could automatically enrich an alert (e.g. “user account suspicious login”) with a check against dark web data – “has this user’s password been leaked online?” – and immediately inform the analyst or end-customer if a compromise is found. It’s a powerful addition to threat intelligence feeds for incident response and identity protection. And because the search can be parameterized by different fields (username, IP, password, etc.), creative use cases abound – you might even integrate it into your vulnerability management workflow to see if any known exploits (by CVE) or specific indicators have associated leaked data. The possibilities for proactive threat hunting are huge.

All three APIs support an optional query_tags in the request, letting you attach metadata (like a customer ID or use-case tag) to each query for your own tracking. The responses also include metadata such as timestamps and result counts. Crucially, every request is authenticated with your API key and logged on FullHunt’s side, providing traceability (FullHunt maintains audit logs for the OEM API usage). This means you can monitor how your integration is being used and ensure it’s in line with any usage quotas or compliance needs.

Integration Examples & Workflows

To illustrate how the OEM Intelligence API can be leveraged in real-world scenarios, let’s walk through a few example workflows that a security vendor might implement:

Continuous Attack Surface Monitoring (MSSP platform)

If you’re an MSSP managing dozens of clients, you can integrate the Attack Surface API to run on a schedule (say nightly or weekly) for each client’s domain. Each run fetches the latest external asset list. You can then automatically compare it to the last known list and detect changes. New host discovered? Your platform can raise an alert or open a ticket in the client’s queue: “A new subdomain ‘staging.acme.com’ was detected this week, pointing to an IP in AWS – please verify if this is expected.” Likewise, if a previously seen host now has an open port 22 exposed where it didn’t before, that could indicate a security change worth investigating. Essentially, FullHunt’s data becomes the eyes on the outside of each client’s network, and your platform acts as the brain to decide what to do with that data. Multi-tenant tagging ensures each domain’s results are tracked to the right client. The outcome is a value-add service: Attack Surface Monitoring as a Service, powered by FullHunt in the backend but delivered through your operations.

Third-Party Risk Assessment (GRC workflow)

In a GRC or vendor risk management application, assessing a new partner or vendor often requires gathering information about that organization’s size, industry, and any past breaches. By integrating the Organizations Search API, your platform can auto-populate these details. For example, when a user enters a vendor name, your system calls the API and fills out: Company X, ~1,200 employees, HQ in London, sector = Healthcare. It might also display a highlight: “Security incidents: 1 – Data breach in 2019 exposing 200k patient records.” This equips the risk assessor with instant context, prompting deeper questions or controls if needed. It saves hours of manual research per vendor. Additionally, if you maintain a dashboard of all critical suppliers, you could periodically re-check each via the API to catch any newly reported breaches (e.g. if one of your suppliers gets hacked and it’s noted in the data, you’d want to know ASAP). This integration turns FullHunt’s intel into a proactive risk monitoring tool within your product.

Product Contextualization (Security Analytics platform)

Imagine a security analytics platform that investigates threats across multiple companies. When an analyst is looking at a particular threat actor or campaign, they might have a list of target organizations. Using FullHunt’s APIs, the platform can provide one-click context: For each organization, fetch their profile (Org API) to see what that company does, and fetch their attack surface summary (Attack Surface API) to see what infrastructure they have exposed. This can help the analyst understand why that threat actor might be interested (e.g. targeting all fintech companies with open Jenkins servers). It’s an enrichment step that adds narrative and depth to threat intelligence reporting.

These examples scratch the surface of what’s possible. The flexibility of FullHunt’s OEM API means if you can think of a security use-case involving external intelligence, you can likely implement it with a bit of API glue. From augmenting vulnerability scanners with external context, to feeding SOC runbooks, to enhancing security ratings, the integration potential is vast.

Breach Alert Enrichment (XDR/SIEM)

Suppose your XDR platform generates an alert for unusual activity on an admin user account. Through the FullHunt OEM integration, your platform can automatically query the Dark Web API for that user’s email as soon as the alert triggers. If the API returns that this email appears in a recent credential dump with a known password, your platform could attach a note to the alert: “Credentials for this user were found in a 2024 breach (password: Password123).” This gives the analyst immediate insight that the account may be compromised due to password reuse. Your platform could even automate a higher severity rating or prompt an on-demand password reset workflow. All of this happens seamlessly — the analyst doesn’t have to pivot to an external breach-check service; the intelligence is injected right into the alert timeline. Over time, such enrichment dramatically improves incident response by adding context. It also adds value for your customers, as they get proactive breach notification embedded in your service.

Example of FullHunt’s data in action: Through the OEM Attack Surface API, you can retrieve this attack surface data (thousands of subdomains and hosts for a given domain, complete with IPs and metadata) in JSON format and integrate it into your own tools. In practice, this means within your platform, a client could enter a domain like “acme.com” and get an instant inventory of results just like the list shown above – enabling proactive management of external assets and exposures.

Seamless Integration and Support

Getting started with the FullHunt OEM Intelligence API is designed to be developer-friendly. If you’re familiar with RESTful APIs and JSON, you’ll find FullHunt’s API straightforward. You authenticate with an API key via a header, and then send POST requests to specific endpoints under the /api/v1/oem/ path for the features described. FullHunt’s documentation site provides copy-pastable curl examples for each endpoint, making initial testing a breeze. For instance, to search the attack surface data for a domain, you’d use an HTTP POST to /oem/atack-surface/search with a JSON body like:

{ 
 "type": "domain",
 "query": "acme.com",
 "query_tags": {"client": "ACME Corp"}  
}

And you’d receive back a JSON response containing an array of all matching leaked records related to “acme.com”. The patterns are similar for the other endpoints (with slight differences in required fields), so once you integrate one, adding the others is intuitive.

FullHunt also ensures that OEM partners have the support they need. When you come on board as an OEM partner, you will coordinate with FullHunt’s team to get your API key provisioned with the proper access. Typically, this involves contacting FullHunt sales or support – as noted in the documentation, OEM access is enabled for partners by request. After that, you’re free to integrate and test. During integration, if you have questions, FullHunt’s technical support is available. They can help with optimizing queries, understanding the data schema, or troubleshooting any issues. Additionally, because OEM integrations can be complex, FullHunt is open to feedback – if you need a certain feature or data point exposed via the API to support your use case, we can accommodate it or put it on the roadmap.

On the operational side, FullHunt’s OEM API comes with built-in user credit management and audit logs for queries.

Ready to Unlock FullHunt Intelligence in Your Platform?

The FullHunt OEM Intelligence API represents a bold step towards collaborative innovation in cybersecurity. By opening up our intelligence via OEM channels, we aim to empower other security providers to deliver better outcomes for end users. Whether you’re an MSSP looking to enhance your managed services or a security product company aiming to expand features, FullHunt’s data can become a force-multiplier for your offerings.

We invite you to explore what FullHunt OEM Intelligence can do for your organization. Dive into our developer documentation (api-docs.fullhunt.io) to see the technical details and example responses. If you’re interested in becoming an OEM partner, contact our team (sales@fullhunt.io or via our website) to discuss access and partnership options – we’ll work with you to get the API enabled on your account and ensure a smooth onboarding.

With FullHunt, you can deliver attack surface mapping, organization intelligence, dark web monitoring as an integrated part of your service – all backed by FullHunt’s proven technology and extensive data. We’re excited to see how you will innovate with these capabilities at your fingertips.

Download an in-depth documentation report about the OEM Intelligence API Product

OEM Intelligence API - in-depth Product Documentation

Unlock the power of FullHunt OEM Intelligence API today, and give your platform the definitive edge in security intelligence.

Best Regards,
Mazin Ahmed

FullHunt Exciting New Features and Free APIs! 🚀

2024-07-08T00:00:00-05:00

Explore FullHunt's new features and free APIs. The FullHunt team has been working on exciting attack surface discovery and threat intelligence features - #JoinTheHunt.

Exciting Updates from FullHunt – New Features and Free APIs! 🚀

We’ve got some exciting news to share. Over the past few months, we’ve been busy building awesome new products and features at FullHunt, and we can’t wait to tell you all about them.

What’s Coming Up?

We’ve been working on some exciting new products, features, and tools that will be rolling out in the next few weeks. Keep an eye out for our announcements — these updates are going to make a big difference in your attack surface discovery!

Free Community APIs – Now Available!

We’ve also launched new free community APIs to help you discover your external attack surface more effectively.

Introducing Data Intelligence APIs

Data Intelligence APIs are designed to help you run threat intelligence and large-scale internet investigations by querying the FullHunt Database for a wide range of use cases and characteristics.

FullHunt runs one of the largest databases for attack surfaces on the Internet, and we’re happy to make it available to the community.

We have rolled out the Data Intelligence product and APIs to a closed number of enterprise customers, and they’re already finding it useful in their security automation and investigations. The APIs are available now, and we think they’ll be a great addition to your security toolkit.

The results are limited for community accounts. Enterprise accounts gain full access to Data Intelligence API.

Check out the new APIs here: Data Intelligence APIs

We will announce it more in-depth in upcoming weeks.

We Want to Hear from You

Your feedback is super important to us. We’d love to hear what you think about the new features and how we can keep improving.

Share your thoughts with us here

Thanks for being a part of the FullHunt community. We’re really excited about these new updates and can’t wait to support you even more.

#JoinTheHunt

Best Regards,
Mazin Ahmed
Founder & CTO, FullHunt

Are you an enterprise that is looking to solve Attack Surface Discovery, continuous monitoring, security scanning, and custom-developed tools and APIs? Please reach out to us at team@fullhunt.io, and we will be happy to solve your challenges. Please request a FullHunt Enterprise trial and we will be happy to solve your challenges.

Discover unknown assets today and protect your organization

Log4J-scan update: Detection for Apache Commons Text RCE (CVE-2022-42889)

2022-10-20T00:00:00-05:00

FullHunt released an update to Log4J-Scan to detect Apache Commons Text RCE (CVE-2022-42889).

Detecting Apache Commons Text RCE (CVE-2022-42889)

The Apache Commons Text RCE (CVE-2022-42889) is a critical vulnerability that is highly similar to Log4J RCE. Successful exploitation of this vulnerability allows full remote code execution on affected services. The vulnerability has been ranked a CVSS score of 9.8/10.

We have tested the vulnerability in our local lab and confirmed the potential severity of this vulnerability.

FullHunt released an update to identify Apache Commons Text RCE (CVE-2022-42889). We recommend patching it as soon as possible. If help is needed in scanning and discovering this vulnerability on your infrastructure, please get in touch at (team@fullhunt.io).

Demo

log4j-scan Project: github.com/fullhunt/log4j-scan

Are you an enterprise that is looking for help with scanning for Apache Commons Text RCE (CVE-2022-42889), discovering all the external internet-facing assets, network services, applications, services, and endpoints? Please request a FullHunt Enterprise trial and we will be happy to solve your challenges.

Discover unknown assets today and protect your organization

Best regards,
Mazin Ahmed
The FullHunt Team

Detecting Spring4Shell RCE CVE-2022-22965 at scale

2022-04-08T00:00:00-05:00

FullHunt developed an open-source tool for discovering Spring4Shell RCE at scale.

Detecting Java Spring RCE at scale

The Spring4Shell RCE is a CVE-2022-22965 critical vulnerability that has been exploited by threat actors this weekend. At FullHunt, we developed, spring4shell-scan: a fully automated, reliable, and accurate scanner for finding Java Spring RCE (Spring4Shell). It was mainly available for our customers during the past days. We’re glad to be open-sourcing it now!

FullHunt vs. Spring4Shell

As soon as the Spring4Shell vulnerability was announced, we started investigating the exploitability of these vulnerabilities. The FullHunt platform already supports the discovery and automatic classification of Spring apps. This was a life-saver feature to be able to map all Spring apps within hundreds of thousands of assets while the vulnerability has been released.

We focused on researching the detection of Spring4Shell CVE-2022-22965 vulnerability and the Spring Cloud RCE CVE-2022-22963.

How to detect Spring4Shell and Spring Cloud RCE?

The Spring4Shell is essentially a Java Deserialization vulnerability that can be highly noisy and sensitive during its detection and exploitation. The current way that we observed to be used by threat actors makes use of the initially published Proof of Concept that was shared online. The initial Proof of Concept takes an unsafe approach where a JSP web-shell is uploaded when knowing the correct path (while being set to a default path). This is inaccurate, can be easily detected, can definitely be easy to evade.

The approach that FullHunt has taken works by sending a corrupted raw object that triggers an exception when deserialized. Once an exception is detected, a check is sent to validate that the payload has effectively triggered an exception - so that if an API endpoint for instance is already returning 4XX or 5XX errors, it wouldn’t cause a False Positive. Additionally, within spring4shell-scan, payloads are tested in different HTTP methods, as we have higher accuracy in testing in different HTTP methods.

This approach also applies to Spring Cloud CVE-2022-22963, where a malicious SpEL query can lead to remote code execution. We have found that sending corrupted SpEL queries can be a valid method for discovering the Spring Cloud CVE-2022-22963.

WAF rules? We bypassed them during our tests

The main approach that several companies have used to protect against the new Spring4Shell (CVE-2022-22965) and CVE-2022-22963 are through WAF rules provided by vendors. We have developed payloads that have been tested against several WAF vendors, and it was confirmed to be bypassing the majority of WAF rules during our tests. It’s advised to contact your WAF vendor to make sure that the new techniques developed by FullHunt are blocked.

We mainly recommend that companies update their Spring setup and dependencies as the approach for remediating these sets of vulnerabilities. Virtual patching through WAF should be only taken as a temporary approach.

As many companies are facing challenges discovering its Spring deployments. We have been helping companies map its Spring deployments, scan them for all of the released Spring vulnerabilities, and run continuous security scanning.

Demo

spring4shell-scan Project: github.com/fullhunt/spring4shell-scan

Are you an enterprise that is looking for help with scanning for Spring4Shell, discovering all the externally public assets, network services, applications, services, and endpoints? Please request a FullHunt Enterprise trial and we will be happy to solve your challenges.

Discover unknown assets today and protect your organization

Best regards,
Mazin Ahmed
The FullHunt Team

Detecting Log4j RCE CVE-2021-44228 at scale

2021-12-13T00:00:00-06:00

FullHunt developed an open-source tool for discovering Apache Log4j RCE CVE-2021-4428 at scale.

Detecting Apache Log4J RCE at scale

The Apache Log4J RCE CVE-2021-4428 is a critical vulnerability that has been heavily exploited by threat actors this weekend. At FullHunt, we developed, log4j-scan: a fully automated, accurate, and extensive scanner for finding Apache Log4j RCE. It was mainly available for our customers during the past days. We’re glad to be open-sourcing it now!

How log4j-scan works?

Log4j-scan fuzzes HTTP request headers, POST data, JSON body, and all possible points where a Log4j entry can be generated from an HTTP request. It also has WAF bypass payloads that can be tested to evaluate the security of WAFs and make sure that WAFs are blocking Log4J variants.

It uses DNS OOB callback to validate whether an host is affected, and it does not attempt to exploit the RCE vulnerability.

FullHunt Enterprise customers have already been tested once the vulnerability was released, and all FullHunt Enterprise customers have this RCE resolved.

Demo

log4j-scan Project: github.com/fullhunt/log4j-scan

Are you an enterprise that is looking for assets discovery, continuous monitoring, security scanning, better support, more features, and custom-developed tools? Please reach out to us at team@fullhunt.io, and we will be happy to solve your challenges.

Discover unknown assets today and protect your organization

Best regards,
Mazin Ahmed
The FullHunt Team

FullHunt 💜 Open-Source: Integration with Amass + SpiderFoot

2021-12-07T00:00:00-06:00

FullHunt Public API is now a data provider for Amass + SpiderFoot!

FullHunt 💜 Open-Source

If there is one thing we’re excited about, it’s the Open-Source community. Today, we’re glad to announce the integration of FullHunt with two major security tools within the OSINT industry: Amass + SpiderFoot. FullHunt is now a data provider that powers the OSINT and passive scanning for Amass and SpiderFoot to discover attack surfaces. This comes in addition to TheHarvester too, which came last month.

FullHunt integration with Amass 🚀

The new release of Amass includes the FullHunt API as a data source of the subdomain enumeration phase of Amass.

I have been a big fan of Amass since its release a few years ago, I’m glad to see this happening!

Tweet: https://twitter.com/owaspamass/status/1459019750437236759

FullHunt integration with SpiderFoot Framework🕷️

SpiderFoot was one of the first adopters to FullHunt. as soon as the FullHunt API reached beta, SpiderFoot has developed a module for FullHunt and a Pull Request was ready by @_bcoles.

It’s really exciting to see SpiderFoot integrating FullHunt for OSINT. I especially liked the use of several data points FullHunt is probing to build an OSINT interface.

FullHunt API Documentation

You can find the API documentation for the public API at: api-docs.fullhunt.io.

API Keys

You can obtain an API key by signing up for a free account at FullHunt. If you’re an enterprise customer, your account receives unlimited access to the FullHunt public API.

This is just the beginning…

We’re in the process of integrating FullHunt with the Metasploit framework to allow Attack Surface Discovery within seconds right from the Metasploit console.

PR: https://github.com/rapid7/metasploit-framework/issues/15857

Would you like to contribute to the Metasploit and build an Auxiliary Module for discovering attack surfaces using FullHunt.io? This will be a great addition :)

Huge Thanks to the amazing Open-Source contributors

This would not have been possible without the amazing Open-Source contributors:

Jeff Foley: for building Amass, and developing the excellent integration of FullHunt on ADS language.
@_bcoles: for building the extensive SpiderFoot integration that utilizes several FullHunt datapoints on its OSINT gathering.
Everyone at SpiderFoot, theHarvester, and Amass for being awesome.

Are you an enterprise that is looking for more features, continuous monitoring, security scanning, better support, more features, and custom-developed tools? Please reach out to us at team@fullhunt.io, and we will be happy to solve your challenges.

Discover unknown assets today and protect your organization

Best regards,
Mazin Ahmed
The FullHunt Team

FullHunt Blog

wp2shell (CVE-2026-63030): Pre-Auth RCE Chain in WordPress Core

Background

Identify wp2shell Exposure with FullHunt

The vulnerability

Bug 1: Array index desynchronisation in serve_batch_request_v1

Bug 2: Re-entrancy in serve_request and rest_api_loaded

Bug 3: SQL injection in WP_Query via string author__not_in

The attack chain

What determines whether SQLi becomes RCE

Why these bugs existed

Affected versions

Mitigation

Indicators of compromise

References

FullHunt Releases Agentic AI for Attack Surface Intelligence

FullHunt Releases Agentic AI for Attack Surface Intelligence

Ask in Simple Words

40+ AI-Accessible Security Tools

Available on FullHunt Professional Accounts!

Integration is Simple

FullHunt 💜 Open-Source: 39,408 Exploits from 0day.today is Back Online

Open-Source Release: 0day.today Exploits Archive

What is the 0day.today Archive?

Credits

Getting Started

Introducing FullHunt Vulnerability Intelligence

Introducing FullHunt Vulnerability Intelligence

What is FullHunt Vulnerability Intelligence?

Key Features

Available Through Console and APIs

Continuous Security Innovation

Introducing FullHunt’s OEM Intelligence API for Security Platforms

Introducing FullHunt’s OEM Intelligence API for Security Platforms

What Does the OEM Intelligence API Include?

Attack Surface Search API

Organizations Search API

Dark Web Search API

Integration Examples & Workflows

Continuous Attack Surface Monitoring (MSSP platform)

Third-Party Risk Assessment (GRC workflow)

Product Contextualization (Security Analytics platform)

Breach Alert Enrichment (XDR/SIEM)

Seamless Integration and Support

Ready to Unlock FullHunt Intelligence in Your Platform?

Download an in-depth documentation report about the OEM Intelligence API Product

FullHunt Exciting New Features and Free APIs! 🚀

Exciting Updates from FullHunt – New Features and Free APIs! 🚀

What’s Coming Up?

Free Community APIs – Now Available!

Introducing Data Intelligence APIs

We Want to Hear from You

Log4J-scan update: Detection for Apache Commons Text RCE (CVE-2022-42889)

Detecting Apache Commons Text RCE (CVE-2022-42889)

Demo

Detecting Spring4Shell RCE CVE-2022-22965 at scale

Detecting Java Spring RCE at scale

FullHunt vs. Spring4Shell

How to detect Spring4Shell and Spring Cloud RCE?

WAF rules? We bypassed them during our tests

Demo

Detecting Log4j RCE CVE-2021-44228 at scale

Detecting Apache Log4J RCE at scale

How log4j-scan works?

Demo

FullHunt 💜 Open-Source: Integration with Amass + SpiderFoot

FullHunt 💜 Open-Source

FullHunt integration with Amass 🚀

FullHunt integration with SpiderFoot Framework🕷️

API Keys

This is just the beginning…

Huge Thanks to the amazing Open-Source contributors

Bug 1: Array index desynchronisation in `serve_batch_request_v1`

Bug 2: Re-entrancy in `serve_request` and `rest_api_loaded`

Bug 3: SQL injection in `WP_Query` via string `author__not_in`