A business logic flaw that let anyone redirect an invitation, create accounts under a stolen identity, and generate ghost registrations — without a single line of exploit code.

The registration page loaded.

I expected to see [email protected] pre-filled in the email field, locked, untouchable. That's how invite flows are supposed to work — you invite someone, they get a link, they arrive at a form already bound to their identity. The system knows who it's expecting.

The field wasn’t locked.

It was blank.

I stared at it for a second. Typed [email protected]. Hit submit.

Account created. No errors. No warnings. No validation failures.

Then I went to the admin dashboard. It showed [email protected] — status: Accepted.

The person at that email had never registered. Never clicked past the invite. Had no account on the platform whatsoever. But LG’s backend was completely confident they had.

That’s the bug. No payload. No injection. One email field, one submit, and the entire invite authorization model was gone.

Why This Bug Is Harder to Find Than It Looks

Business logic flaws don’t announce themselves.

There’s no stack trace, no HTTP 500, no scanner alert. The application doesn’t break — it does exactly what it’s designed to do. The problem is that what it’s designed to do isn’t what anyone actually thought it would do.

This particular class of bug hides inside features that look secure because the obvious tests pass. Rate limiting? Works. Token structure? Solid. Race conditions? Handled. The engineer who built this clearly had security in mind. The hard parts were done right.

What failed was a single assumption that nobody wrote a test for: that the person using the invite link is the same person the invite was sent to.

I’ve found this pattern before. The surface is locked. The assumption underneath it isn’t.

I want to tell you how I got here — because the path matters as much as the finding.

Recon at Scale: ShrewdEye and a Live Subdomain

I wasn’t chasing a bounty on this one. I wanted a Letter of Appreciation from LG — a clean, documented find on a company that takes its platform seriously. That framing changes how you hunt. You’re not looking for the fastest path to a bounty. You’re looking for something worth remembering.

Recon started with ShrewdEye — one command, raw output, no UI friction:

wget https://shrewdeye.app/domains/<domain_name>.txt

Hundreds of subdomains came back. I filtered for live 200 OK responses. One subdomain stood out — I’ll call it xyz.redacted.lg.com. It wasn't just alive. It was running a full enterprise-facing portal: login pages, user dashboards, team management, an invite system.

The kind of place where real functionality lives and real assumptions go unchecked.

I created an account. Mapped the feature set. Then went straight to the invite flow — not to break it, but to use it. That’s the step most hunters skip. Using a feature the way it was designed tells you more about where the logic breaks than throwing payloads at it cold.

The Tests That Returned Nothing

The invite feature looked clean.

You enter an email, send the invite. Target receives an email. They click the link, register, join the team. Standard enterprise onboarding.

I tested the obvious vectors:

Rate limiting — 50 invites in rapid succession. Throttled at a reasonable threshold. Solid.

Race conditions — Parallel registration requests on the same token. No duplicate accounts, no state corruption. Handled.

Token structure — Checked whether invite tokens were sequential, time-based, or predictable. They weren’t. Randomized. Good.

Invite flooding — Hammered the system to see if it’d lose track of pending invites. Nothing.

Everything held. At this point, most hunters close the tab. The feature passed all the tests that require actual tooling. Moving on seems rational.

I almost did.

Then I asked the question I should have asked first — the one that felt too obvious to be worth testing:

“Does the system actually verify that the person using the invite link is the person the invite was sent to?”

This is the kind of question that feels beneath you after a few months of hunting. Surely they checked that. That’s table stakes. Nobody builds an invite system and forgets to lock the destination email.

I want to be honest about something here: I hesitated to run this test. It felt too basic. I had a flash of something like embarrassment — if this works, what does that say about how thorough I’ve actually been? I almost skipped it.

That hesitation is the bug. Not in the code. In the hunter.

The Field That Wasn’t Locked

I sent an invite to [email protected].

The email arrived. I opened it. Clicked the link.

The registration page loaded. I expected the email field to be pre-filled and frozen — the system knowing who it’s waiting for. Instead: blank field, fully editable, cursor blinking.

I thought: frontend only. Cosmetic. The backend is definitely validating the token against the invited address. This is a UI quirk.

I typed [email protected]. Added a password. Submitted.

New account created. No error. No mismatch flag. No warning that the email didn’t match the invite.

Then I checked the admin panel.

[email protected] — Accepted.

The invited user had never touched anything after the initial email. No account. No session. Nothing. But the system had logged them as an accepted member of the team, their registration complete.

The attacker — me, in this controlled test — was inside with a fresh account, fully functional, completely invisible.

The Ghost Account Problem

This is where it stops being an interesting edge case and becomes an actual structural failure.

The invite token wasn’t bound to the email address it was sent to. The backend asked one question: is this token valid and unexpired? It never asked the follow-up: does this token belong to whoever is submitting this form?

Think of it like a hotel key card.

A key card opens the room it’s programmed for. That’s the design. What LG’s system built was a key card that opened whatever room the person carrying it claimed they were assigned to — and then logged the original booking as checked in.

The exploit chain is embarrassingly simple:

1. Attacker creates an account on the platform.
2. Attacker invites [email protected] using the legitimate invite feature.
3. Invite email is sent to [email protected].
4. Attacker opens the invite link themselves (they don’t need to intercept anything — they sent the invite, they can request the same link flow, or they simply use the token from their own invite queue).
5. Attacker changes the email field to any address they control.
6. Submits. New account created under attacker’s email.
7. Backend logs [email protected] as having accepted.
8. Repeat indefinitely.

No sophisticated tooling. No chained vulnerabilities. No privilege escalation. One editable field, one submit.

The downstream consequences go beyond unauthorized access:

Analytics are broken. The platform thinks invited users accepted. They didn’t.

Audit logs are falsified. Every ghost registration looks legitimate in the dashboard.

Trust assumptions collapse. If your access model is invitation-based — if you believe “only people I invited can join” — this bug removes that guarantee entirely.

The attack is invisible. The real user never registers. The system never generates a conflict. There’s nothing to alert on.

The Part That Actually Matters

Here’s what I keep returning to when I think about this finding.

The hard parts of this invite system were implemented correctly. Rate limiting. Token randomness. Protection against flooding. Whoever built this wasn’t careless — they made real decisions about the attack surface.

The one thing that broke the whole model was a single unanswered question that sounds almost embarrassing to ask out loud: “Is the email field locked?”

Most hunters develop a hierarchy of tests. The complex ones go first — the ones with tooling, with chaining, with lateral thinking. The sanity checks go last, or get skipped entirely, because they feel beneath the skill level that got you here.

But the most damaging bugs I’ve found — on this program and on others — have lived behind the boring questions. Not because developers are incompetent. Because no one thought the obvious thing needed verifying.

The sophisticated surface hides the trivial gap. Every single time.

What LG’s Team Saw

I documented the finding cleanly:

Bug type: Business logic flaw — invite token not bound to invitee email address

Impact: Unauthorized account creation, ghost registration logging, complete bypass of invite-based access control

Steps to reproduce:

1. Send invite to any email address
2. Open the resulting invite link
3. Change the email field on the registration form to any other address
4. Submit — account is created under the modified email, original invite marked as accepted

Severity: Medium to High, depending on how the platform uses invitation-based access control

I submitted this for a Letter of Appreciation, not a bounty. LG acknowledged the finding.

The Lesson That Isn’t About LG

I want to be clear about what this bug is actually telling us.

This isn’t an LG-specific failure. I’ve seen variations of this logic error on platforms across every industry — the email gets passed to the frontend, the backend trusts that nobody would ever think to change it, and the invite system becomes an honor system nobody designed.

The dangerous assumption isn’t that systems are secure. It’s that the obvious thing was obviously done.

Every time you’re hunting and you catch yourself thinking “surely they checked that” — stop. Test it. Write the stupid check. The cost is 30 seconds. The upside is finding the one thing everyone else assumed was fine.

A Question I Don’t Have a Clean Answer For

This bug was live on a subdomain of a company with the resources, the engineering team, and the security program to find it before I did.

If it was here, how many invitation systems at smaller, less scrutinized platforms are running the exact same broken logic right now — with no one to send the invite link to [email protected] and ask the embarrassing question?

Do you think most companies with invite systems have ever actually tested whether the invited email is verified server-side — or do they assume the frontend handles it?