{"slug": "a-step-by-step-guide-how-to-hack-webhooks", "title": "A step by step guide how to hack webhooks", "summary": "This article explains how webhooks, which are simple HTTP callbacks used for service-to-service communication, can be exploited by attackers for data exfiltration, server spamming, and business logic abuse if not properly secured. It provides guidance for both threat hunters and bug bounty hunters on finding leaked webhook endpoints through public search engines and assessing their impact, emphasizing that the severity of vulnerabilities depends on implementation details like verification and workflow ordering. The post also notes that while many discovered webhooks may be benign, they can reveal internal workflows or serve as gateways for attacks such as pipeline abuse or phishing-style flows.", "body_md": "A step by step guide how to hack webhooks\nTable of Contents\nA step by step guide how to hack webhooks\nkinda\nthis is a crossover post between threat hunters and bug hunters. at the end of the day it is all about hunting.\nthis post will talk about hunting and threat hunting using webhooks\nfor those who don’t know what webhooks are: webhooks are an easy way to send messages from one service to another. they are simple HTTP callbacks that notify endpoints when events happen\nHow bad guys can abuse webhooks⌗\nWebhooks are convenient for automation. bad actors love convenience too. here are common ways webhooks become an attack surface\n-\nAttackers can use webhooks to exfiltrate data to their servers\nIf a webhook URL leaks publicly other people can spam the receiving servers. what’s the worst that can happen from spamming servers right? overload data leakage or workflow abuse -\nWebhooks mistakenly trusted by backend systems can be a gateway into business logic\nIf a backend trusts incoming webhook calls without proper verification attackers could trigger actions that should be protected. this is not always a flashy RCE exploit many times the damage is business logic abuse -\nPipeline webhooks can reveal internal build or deployment workflows\nA webhook used to trigger a CI pipeline can hint at how a company deploys code. with that context you can look for weak spots like unsafe handling of inputs naive template rendering or backend endpoints that echo back unvalidated data\nCombine this with an email analogy\nA leaked webhook can act like a gateway into a company. attackers can spam webhooks and cause phishing style flows without even sending email. the attack might be blind at first because you do not know how the backend is implemented however if you find the webhook in context on a website the surrounding code or assets may reveal enough to make a focused higher impact test possible\nReal world examples⌗\nI have seen ecommerce sites use webhooks for order notifications. when implementations assume the webhook is authoritative there can be business logic abuse. conceptually you could cause an order to appear to be paid if the system trusts the webhook to confirm payment. if the backend cross checks payment status then there is no issue. if the site relies solely on the webhook then fulfillment might happen without payment (most modern systems cross-validate payment status)\nthe devil lies in the details of how webhooks are implemented. small differences in timing verification or workflow ordering change the impact dramatically\nHunting webhooks in the wild⌗\nThis part is the fun bit for threat hunters. you can use internet search engines that index web assets to find webhook endpoints living publicly. as an informal check i ran a quick search on FOFA and found thousands of results for discord and slack webhook patterns. that shows how many webhooks leak into public indexes\nKeep in mind public counts are a signal not a final verdict. many results will be benign or intentionally public. use additional context to prioritise targets such as where the webhook appears what page triggers it and whether the surrounding code reveals internal workflows\nFrom a pentester and bug hunter perspective⌗\nWhen you find a webhook used to trigger a pipeline that alone is a useful hint. that hint can lead to blind code injection reflected XSS or other issues depending on how the pipeline uses data. sometimes it is low noise and high payoff. kinda fun right\nfor bug bounty submissions you often need to show impact not just possibility. many webhook issues are out of scope for a program so be clever in demonstrating a realistic impact. show how the webhook maps to a meaningful business function. provide a proof of concept that respects program rules and follows responsible disclosure\nThreat model and scope⌗\nExplicitly state what you are testing: public webhook URLs found in code repos pages or search indexes versus internal webhooks discovered by credential leakage. this clarifies whether an action is discovery only or active testing\nTiming and ordering issues⌗\nNote race conditions where webhook fires before payment confirmation or where webhook ordering can be abused to replay or reorder events. recommend idempotency tokens and status checks\nTelemetry and detection⌗\nList concrete signals defenders can add to logs: source IPs user agents request body hashes timestamp headers signature headers response status codes unusually high delivery rates. add SIEM alert examples\nHow to find webhooks reliably⌗\nSearch patterns credentials scanning repository history look for hostnames like hooks.slack.com\ndiscord.com/api/webhooks\ndiscordapp.com/api/webhooks\n*.webhook\ncheck JS embedded in pages network calls visible in browser devtools and use git secrets scanning\nMitigations summary (quick)⌗\nRotate webhook URLs and secrets enforce HMAC signatures and timestamp checks add IP allowlists when possible require secondary confirmation for financial actions add rate limits log deliveries with request ids\nDetection rules and examples⌗\nSimple regex to detect typical webhook URLs in code or logs\n- Slack pattern:\nhttps?://hooks\\.slack\\.com/services/[A-Z0-9]+/[A-Z0-9]+/[a-zA-Z0-9_-]+\n- Discord pattern:\nhttps?://(canary\\.)?discord(app)?\\.com/api/webhooks/\\d+/[A-Za-z0-9_-]+\nSIEM rule idea\nTrigger when outbound POSTs to known webhook hosts exceed baseline by X within 5 minutes or when same webhook receives more than N deliveries from diverse source IPs within T minutes\nSafe curl examples⌗\nThe examples below show how to send benign messages to incoming webhook endpoints. replace WEBHOOK_URL\nwith the webhook you control or a test webhook belonging to you. Do not send tests to other people systems\nSlack incoming webhook simple message⌗\n# replace WEBHOOK_URL with your slack incoming webhook URL\ncurl -X POST \"WEBHOOK_URL\" \\\n-H \"Content-Type: application/json\" \\\n-d '{\"text\":\"test from security research safe PoC only. do not run on other people systems.\"}'\nSlack advanced block payload⌗\ncurl -X POST \"WEBHOOK_URL\" \\\n-H \"Content-Type: application/json\" \\\n-d '{\n\"blocks\": [\n{ \"type\":\"section\", \"text\": { \"type\":\"mrkdwn\", \"text\":\"*PoC* webhook delivered by security test\" } },\n{ \"type\":\"context\", \"elements\":[ { \"type\":\"mrkdwn\", \"text\":\"id: poc-2025-09-17\" } ] }\n]\n}'\nDiscord incoming webhook simple message⌗\n# replace WEBHOOK_URL with your discord webhook URL\ncurl -X POST \"WEBHOOK_URL\" \\\n-H \"Content-Type: application/json\" \\\n-d '{{\"content\":\"safe PoC message from security researcher. only run on your own webhooks.\"}}'\nDiscord embed example⌗\ncurl -X POST \"WEBHOOK_URL\" \\\n-H \"Content-Type: application/json\" \\\n-d '{\n\"username\":\"PoCBot\",\n\"embeds\":[\n{\n\"title\":\"PoC Delivery\",\n\"description\":\"This is a safe test embed. id: poc-2025-09-17\",\n\"footer\":{\"text\":\"do not test on production without consent\"}\n}\n]\n}'\nQuick defensive checklist⌗\n- Treat webhook URLs as secrets do not embed them in client side code\n- Verify signatures when supported and enforce timestamp checks\n- Rotate secrets and revoke leaked URLs immediately\n- Use idempotency tokens and require secondary checks for financial flows\n- Rate limit and monitor webhook traffic and add alerts for spikes\ndocument the context where you found the webhook the surrounding assets and the likely workflow. that context often turns a blind guess into a reproducible finding", "url": "https://wpnews.pro/news/a-step-by-step-guide-how-to-hack-webhooks", "canonical_source": "https://blog.himanshuanand.com/2025/09/a-step-by-step-guide-how-to-hack-webhooks/", "published_at": "2025-09-17 00:00:00+00:00", "updated_at": "2026-05-24 02:37:42.448111+00:00", "lang": "en", "topics": ["cybersecurity"], "entities": [], "alternates": {"html": "https://wpnews.pro/news/a-step-by-step-guide-how-to-hack-webhooks", "markdown": "https://wpnews.pro/news/a-step-by-step-guide-how-to-hack-webhooks.md", "text": "https://wpnews.pro/news/a-step-by-step-guide-how-to-hack-webhooks.txt", "jsonld": "https://wpnews.pro/news/a-step-by-step-guide-how-to-hack-webhooks.jsonld"}}