A Three-Day Abuse Campaign Against Our Self-Serve Sign-Ups: Load, Lead Spam, and a DNS-Rebinding Attempt Through E-Signature Webhooks

Status at revision 1.0. The campaign ran from 2026-10-20T18:02Z to 2026-10-22T09:01Z, in four phases. Our web-server logs record no request from a Tor exit relay between 09:01:32Z and 14:41Z on 2026-10-22. Every defect it exposed has a deployed mitigation, listed in Section 7. Some items remain open and are listed there too, including a public demo environment that has not reset cleanly since 04:12Z (Section 4). This advisory is incident reporting about our own systems. It names no actor.

Standfirst. An automated web-assessment tool read our security.txt and disclosure policy, later labelled its own traffic "authorized", and spent three days on the features any member of the public can use: the point-of-sale demo, the e-signature product's free sign-up, and the merchant portal's sign-in. First it came from a single address, then from hundreds of Tor exit relays. It caused a 29-minute outage of our operations application. It also registered 234 e-signature webhooks, 225 of them pointed at a public DNS-rebinding service aimed at loopback, Docker-bridge and cloud-metadata addresses. All 7,371 webhook deliveries failed. We found no evidence that any internal service answered, that any account outside our public demos was entered, or that customer data was reached. See Section 6, "What we did not find".

A safe-harbour clause is not an authorization. The tool fetched our security.txt ten minutes after its first request and our disclosure policy within the hour. About ninety minutes after that, it began putting the words "authorized" and "AuthorizedAssessment" in its own User-Agent. Nobody authorized it. A line in a policy that promises not to pursue good-faith researchers does not permit anyone to generate load, create accounts, or probe our internal network.

Advisory ID

LH-2026-005

Published

2026-10-22

Revision

1.0See the revision history.

Severity

MediumA 29-minute availability outage and an unsuccessful request-forgery attempt. No data exposure found.

Traffic Light Protocol

TLP:CLEAR

Class

Abuse of public self-serve featuresIncident report about our own systems.

Author

Daniel Wilson KempFounder & Chief Executive Officer, Lifted Holdings LLC

Related

LH-2026-003Precedent for reporting our own defects.

Every count in this advisory comes from our own web-server access logs, application logs and database, and the window and source of each is stated. None of it can be reproduced from outside, because it is our telemetry. What a reader can check is the indicator feed. The DNS-rebinding host names decode to the addresses we state (Section 5), and the Tor relays are in the Tor Project's public exit lists for those dates.

Section 1Summary

Several of our products let anyone try them without talking to us first. The point-of-sale system has a public demo with a "request a walkthrough" form. The e-signature product has a free sign-up. The merchant portal sends a one-time code to anyone who types an email address. For three days in October an automated tool worked through all of them. On the first day it sent 195,070 requests from one address and filled our demo-request queue with fake companies. Each fake request triggered a notification inside our operations application, and a defect in that notification code leaked database connections until the application stopped answering for 29 minutes. On the second day it switched to Tor, opened two free e-signature accounts with throwaway email addresses, and registered 234 webhooks. A webhook is a URL our server calls when a document event happens. Almost all of these pointed at a public "DNS rebinding" service that makes one hostname alternate between a harmless public address and a private one, a known way to trick a server into calling its own internal network. Our server made 7,371 of those calls. None succeeded. On the third day it came back twice more, mostly against the public demos themselves. We fixed the connection leak, made webhook delivery connect only to the address it had already checked, stopped honouring a header that let a disguised request slip past one of our filters, refused sign-ups from throwaway and non-existent email domains, and blocked Tor exit relays from our sign-up, sign-in and one-time-code endpoints. We found no evidence that the campaign reached customer data, entered any real account, or got an answer from any internal service.

Section 2Key findings

1. Availability was the only harm to service. Integrity harm to our sales queue is listed in Section 4. On 2026-10-20 our operations application was unavailable from 19:59Z to 20:28Z. Its database pool drained because a notification path did not return its connection, and the campaign's volume of demo requests was the trigger. The defect was ours (Section 8).
2. The DNS-rebinding attempt got no answer from any internal service. 234 webhooks were created across two free e-signature accounts between 08:22Z and 09:46Z on 2026-10-21, and 225 of them used the public rebinding service rbndr.us. The targets they encode include 127.0.0.1, the cloud metadata address 169.254.169.254, and several Docker bridge gateways, on ports for the Docker API, PostgreSQL, Redis, Memcached, Elasticsearch and Consul. 7,371 deliveries were attempted and none returned a 2xx status. Every internal target we probed from inside the delivering container either timed out or refused the connection: the Docker-bridge gateways on 2375, 5432 and 6379, and loopback on 2375.
3. Our guard was beatable, and luck held. The webhook guard checked the destination's IP address on one DNS lookup and then let the HTTP client do a second lookup to connect. That gap is the one DNS rebinding exploits. The guard did not stop the attempt. Our network layout did: no internal service answered on the combinations we probed. The guard now connects to the exact address it checked.
4. A header let a disguised request past one filter. Our point-of-sale application honoured X-HTTP-Method-Override. A GET carrying that header ran the POST handler, while our reverse proxy logged and filtered it as a GET. Between 17:58Z and 19:55Z on 2026-10-21 this created 16 demo-request records past a rule keyed on the method. Our edge now rejects any request that carries the header.
5. Sign-in attempts failed. Over Tor on 2026-10-21, 185 phone-code checks against our operations console's sign-in were refused, 107 more were rate-limited, and 18 merchant-portal code guesses were refused. On 2026-10-20, 16,235 merchant-portal code guesses from the first address were all refused. No session was issued.
6. The e-signature paywall held. The two free accounts created 149 draft agreements, and every signer address on them was at the throwaway domain. All 17 attempts to send an agreement were refused with 402, because sending requires a paid account.
7. The last phase stayed inside public demos. Between 06:54Z and 09:01Z on 2026-10-22, 4,205 requests from 43 Tor exit relays entered the point-of-sale and vending public demos through their public demo entry points. They edited demo customers, products and roles, toggled two seeded demo-machine records, and tried to provision and reset demos, which was refused. Demo environments are open to the public by design. They are rebuilt on a schedule and send no real messages.

Section 3Timeline

All times UTC. Counts come from our web-server access logs unless another source is named.

Section 4Impact

Section 5Technical detail

5.1 The DNS-rebinding attempt

A host name of the form <hex-ipv4>.<hex-ipv4>.rbndr.us answers each DNS lookup with one of the two encoded addresses, chosen at random, with a very short time-to-live. A server that checks "is this address public?" on one lookup and then connects on a second has roughly even odds of passing the check with the public address and connecting to the private one. Each webhook paired a public address with a private target. Decoding the 225 rebinding hosts gives these targets, by number of webhooks:

The ports probed included 2375 (the unauthenticated Docker API), 5432, 6379, 11211, 9200 and 8500. The other nine webhooks used ordinary host names.

Observed: 7,371 deliveries, every one for the event envelope.sent, none returning a 2xx status. About 1,000 of them received any HTTP status at all. Each of those went to a public host, or to a rebinding name that resolved to its public half at that moment, and returned 3xx or 4xx. Connecting from inside the delivering container to the Docker-bridge gateways on 2375, 5432 and 6379 timed out, and connecting to loopback 2375 was refused. Inferred: no internal service was reachable on the combinations probed, so the delivery responses carried nothing of value. We note plainly that this is a property of our network layout, not of the guard (Section 8).

5.2 The method-override bypass

Our edge rule for the demo-request endpoint was keyed on the HTTP method. The point-of-sale application's web framework honoured X-HTTP-Method-Override, so a request the proxy saw and logged as GET /demo/lead was handled by the application as a POST. Sixteen records were created this way on 2026-10-21. The durable lesson: a filter keyed on the method has to agree with the application about what the method is. We now reject the header at the edge, so both layers see the same request.

5.3 The self-applied "authorization"

Both User-Agent tokens first appeared at 20:31Z and 20:38Z, more than ninety minutes after the tool fetched our disclosure policy. We record this because other operators will see the same move. A label a tool gives itself is not evidence of permission, and it is not a reason to rate-limit more gently.

Section 6What we did not find

• No evidence of access to customer, merchant or cardholder data. In the logs we examined, no request from a campaign source was authenticated as any account other than the two throwaway e-signature accounts and the public demo sessions.
• No successful sign-in to our operations console or to the merchant portal. Every code guess in our logs was refused or rate-limited, and no session was issued.
• No response from any internal service to a webhook delivery, and no cloud-metadata response. No delivery returned a 2xx status.
• No secret exposed by the sensitive-file probes. Requests for paths such as /.env returned 200 on two of our hosts. Those hosts return the same single-page-application HTML for any unknown path, and we confirmed that by requesting a random non-existent path. No configuration file was served.
• No message to a real person from any demo action. Messaging from demo environments is simulated by design. No agreement was sent, and every signer address was at the throwaway domain.
• No effect on any physical vending machine. The machine records toggled in the vending demo are seeded demo records with no device behind them.
• No payment. We found no transaction attempted or processed from a campaign source.
• No identity. We did not identify who operated the campaign, and we have not tried to.

Section 7Remediation

Still open at revision 1.0: the failing rebuild of one public demo environment (Section 4), withdrawing the draft applications at our payment processor, reviewing the eight API keys issued by the shipping tool's free sign-up (that sign-up has no email-domain policy yet), and making the point-of-sale application itself ignore X-HTTP-Method-Override, so that protection does not depend only on the edge.

Section 8Our own conduct and mistakes

We publish these because the campaign found them, and another operator may have the same ones.

1. A connection leak turned spam into an outage. The code that deduplicates notifications took a database connection and did not return it on one path. At normal volume nobody noticed. At campaign volume it drained the pool in about two hours.
2. Our request-forgery guard resolved the name twice. It checked one DNS answer and connected using another. This is a known class of mistake, and we had it.
3. Free accounts could register webhooks. That gave an anonymous user a way to make our server issue outbound requests to any address they chose.
4. The application and the edge disagreed about the HTTP method. See Section 5.2.
5. Our self-serve flows accepted throwaway and non-existent email domains until 2026-10-21.
6. We called the incident over too early. An internal status check at about 03:00Z on 2026-10-22 concluded the activity had stopped. It resumed at 06:54Z against the public demos. Nothing in that phase went beyond the demos, but the earlier conclusion was wrong, and this advisory was nearly written on top of it.

Section 9Detection guidance for other operators

• Alert on any outbound webhook, callback or URL-fetch target under rbndr.us, or any similar rebinding service. No legitimate customer needs one.
• In any server-side fetch, resolve once, vet that address, and connect to that address. Do not hand the host name back to the HTTP client.
• Reject X-HTTP-Method-Override, X-HTTP-Method and X-Method-Override at the edge unless an application genuinely needs them.
• Treat a User-Agent that claims authorization as an indicator, not a credential.
• Watch database-pool saturation alongside request rates. A form-submission flood can become an outage through a leak that normal traffic never reveals.

Section 10Indicators

The machine-readable feed is lh-2026-005-iocs.csv. Its columns are indicator,type,context,first_seen,source. It contains seven campaign indicators and 306 Tor exit relays that touched our sign-up, sign-in, webhook or demo endpoints during the campaign. A relay seen in more than one phase appears once, with the counts from its first phase, so per-row counts do not sum to the phase totals given above.

Deliberately not in the feed: the addresses of anyone who used our public demos legitimately during the same window, and any address of ours other than the one public address a rebinding host encoded.

Section 11Disclosure

This is a first-party incident on our own systems, and no third party's product was found defective. No abuse report has been filed with the network that hosts the scanning address as of revision 1.0. The address is blocked. If anyone was in fact engaged to assess our systems, we did not engage them, and we ask them to contact us at the address below.

Section 12About, credit and contact

The response, the analysis and this advisory are the work of Daniel Wilson Kemp, Founder and Chief Executive Officer, Lifted Holdings LLC.

Lifted Holdings LLC is a payments and technology company based in Tennessee, operating across merchant payments and connected-device platforms.

Section 13Revision history

TLP:CLEAR. This advisory may be redistributed without restriction. We ask only that Section 6, "What we did not find", and the scope limitation above travel with any excerpt.

Tor, Docker, PostgreSQL, Redis and any other names appearing here are the trademarks of their respective owners. Naming them describes observed traffic and infrastructure, and implies no wrongdoing by those projects or their operators.

Advisory LH-2026-005 · Revision 1.0 · Published 2026-10-22 · TLP:CLEAR · liftedholdings.com/security/advisories/2026-005-self-serve-abuse-campaign
Copyright 2026 Lifted Holdings LLC. All timestamps UTC.