This post has been updated multiple times. BOTH critical vulnerabilities were finally fixed on July 30, 2025 - but only after public pressure forced their hand. The email disclosure they claimed would take 14 months to fix? Fixed in 2 days. The account takeover vulnerability first reported in 2023? Also suddenly fixed after 2 years of lies. This went viral and within 48 hours, they miraculously found solutions to "impossible" problems. Lovense knew about the XMPP email bug since 2017 (Pentest Partners reported it - 8 years ago!). OSINT sites were actively exploiting these vulnerabilities. See all updates below for the full story of Lovense's negligence, lies, and how public exposure accomplished what years of responsible disclosure couldn't.

What Happened

So it all started when I was using the Lovense app and muted someone. That's it. Just muted them. But then I saw the API request and was like... wait, is that an email address? Why is that there?

Initial Discovery
Just muting someone exposed their email - wtf

After digging deeper, I figured out how to turn any username into their email address.

So we had two big problems:

Email Disclosure - Any username could be turned into their email address
Account Takeover - Make auth tokens with just an email, no password needed

How Bad Was It?

The Email Thing

The email disclosure vulnerability was surprisingly straightforward once you understood the flow. Here's exactly how it worked:

The Attack Steps:

Get a GToken with encryption parameters:
- Make a POST request to /api/wear/genGtoken with your account credentials
- This returns a gtoken and encryption keys (x and y parameters)
Look up any username:
- Take any Lovense username you want to get the email for
- Encrypt the username using AES-CBC with the keys from step 1
- Send POST request to /app/ajaxCheckEmailOrUserIdRegisted?email={encrypted_username}
- Include your gtoken and X parameter in headers
Get the encrypted user data:
- The API returns encrypted user information including a fake email
- Decrypt the response using the same AES-CBC keys
Extract the real email through XMPP manipulation:
- Connect to Lovense's XMPP server using your account
- Take the fake email from step 3's API response and convert it to XMPP JID format (@ replaced by !!!, add _w suffix)
- Example: cfc561791785b996b989593402dc41a8!!!lovense.remote.email_w@im.lovense.com
- Add this fake JID as a contact to your XMPP roster
- Send a presence subscription request to that JID
- Fetch your roster - this returns both the fake JID you added AND the user's actual JID with their real email
- Example real JID: [email protected] (which reveals the real email: [email protected])
- The XMPP server links them by ofId, so you can match and extract the real email
- Remove the contact to clean up

The whole process took maybe 30 seconds per username manually, with the script we made though to automate it, it took less than 1 second for a username to be converted to an email. We could have easily harvested emails from any public username list. This is especially bad for cam models who share their usernames publicly but obviously don't want their personal emails exposed.

Taking Over Accounts

While Eva and I were checking out the Lovense Connect app later, we found something even worse (Eva did most of the work) - it was making gtokens (auth tokens) without ever asking for a password. Just an email was enough.
haha yes

The Attack Steps:

Get the target's email - Either from the email disclosure bug or if you already know it (later on we discovered after Krissy came forwards this endpoint worked with usernames too.)
Set up the request parameters:
- userName: The target's email or username
- userType: "0"
- pf: "connect-pc" (platform)
- ver: "1.7.9" (version)
Generate the signature:
- Create an MD5 hash of: {platform}-#-{version}-#-{email}##0
- Append timestamp: {md5hash}-#-{timestamp}
Encrypt the signature using AES-CBC with:
- Key: The app's hardcoded appId (a79643e665bb9833)
- IV: The app's hardcoded appSecret (2DF65319C4D46284)
Send POST request to https://apps.lovense-api.com/api/connect/genGtoken
Get back a valid gtoken - No password needed!

These tokens worked on:

Lovense Extension
Lovense Connect
StreamMaster
Cam101 (through the login link)
Even admin accounts

Cam models use these tools for work, so this was a huge deal. Literally anyone could take over any account just by knowing the email address.

The Timeline (Get Ready for This)

March 26, 2025: We reported both bugs to Lovense with help from Internet of Dongs.

March 26, 2025: They said they're looking at it.

March 27, 2025: They confirmed the bugs exist and they're working on fixes.

March 28, 2025: We also put both bugs on HackerOne.

April 8, 2025: On HackerOne:

Email bug: They said it's "already known and fixed in new version" (not released yet). Paid $1,000 total.
Account takeover: They downgraded it from critical to high saying it "doesn't involve database access." Also paid $1,000.

April 9, 2025: After we explained you can literally take over ANY account including admins, they finally made it critical and added $2,000.

May 30, 2025: We told them nothing was fixed.

June 4, 2025: This is where it gets insane. They said:

Account takeover was "fixed on April 7" (it wasn't)
For the email leak, here's a snippet from their email:

"Following your report, we conducted a thorough investigation and rolled out initial mitigation steps, including a temporary fix for the script path issue you identified. However, resolving the root cause involves deeper architectural work. We've launched a long-term remediation plan that will take approximately ten months, with at least four more months required to fully implement a complete solution. We also evaluated a faster, one-month fix. However, it would require forcing all users to upgrade immediately, which would disrupt support for legacy versions. We've decided against this approach in favor of a more stable and user-friendly solution."

Read that again. They wanted 14 MONTHS to fix it. They could fix it in 1 month but won't because "legacy versions"

June 14, 2025: We sent them a long email saying:

Account takeover still works
14 months is insane
Just make people update their apps
Or use a proxy to hide emails without breaking old apps

We suggested they just proxy the XMPP stuff. It would hide emails without breaking anything, work with old apps, and be quick to implement. They said they'd do it but ignored the idea completely.

The technical reality is messy - their entire XMPP architecture relies on JIDs (Jabber IDs) that directly contain user emails. These JIDs are probably used everywhere: message routing, contact lists, presence status, group chats, device pairing. When your core identifier system exposes the exact data you need to protect, you've got a fundamental architectural problem.

Fixing it properly means touching every part of their chat system - updating databases, rewriting message routing logic, migrating existing contacts and chat histories, and ensuring all their apps can handle the new format. That's months of work with high risk of breaking everything.

They've created v2 HTTP endpoints for functions like muting, changing nicknames, and stick to top that use internal JIDs instead of real emails, but they randomly decide whether to use the v1 or v2 versions.

To understand why this doesn't actually fix anything, you need to know that Lovense's XMPP system uses two types of JIDs:

Email-based JIDs - like [email protected] which directly contain the user's real email
Internal/fake JIDs - like cfc561791785b996b989593402dc41a8!!!lovense.remote.email_w@im.lovense.com which use a hash instead of the real email

The v1 HTTP endpoints directly expose emails because the client sends the email-based JIDs in HTTP requests - anyone monitoring network traffic can see the real emails right there. The v2 endpoints use the internal JIDs instead. But here's the problem - the XMPP server requires you to login using the email-based JID format, and it exposes BOTH types of JIDs, linking them together by an internal identifier (ofId). The XMPP server actively sends out the real email-based JIDs in responses, which the client receives.

This means even if Lovense switched to using only the v2 HTTP endpoints, it wouldn't fix the email exposure because the fundamental issue is in the XMPP layer - the server still exposes the real emails, and anyone who can access XMPP (like through the vulnerability I described) can still extract them. Their v2 HTTP endpoints are security theater because the core XMPP architecture remains broken. A proxy translation layer could mask the emails in XMPP without touching the core system, but they've chosen not to implement it.

June 15, 2025: They came back with new dates:

June 19: "Restrict" email-only gtokens
July 3: Fully remove the bad endpoints

July 28, 2025: Guess what? Still broken:

Emails: Still leaking through XMPP
Account takeover: You can STILL make gtokens with just emails (though the endpoints reject them now - why even allow making them??)

The Real Problem: They Don't Care

They'd rather leave everyone's emails exposed for 14 months than make people update their apps. That June 4th email proves it - they literally chose old app support over user privacy.

The funny thing? After scolding them for their choices they later said they "fully agree that user privacy must take precedence over legacy compatibility."

Where We Are Now (July 28, 2025)

Emails still leak - XMPP roster still gives out emails

Here's proof from today when pinning someone:

The app sends the email in the "jid" param - it got this from XMPP which still leaks it
Account takeover "fixed" - You can still make gtokens with just an email (no password!). All endpoints I've tested reject them now, but why let them be made at all? It's like leaving your door open with a "do not enter" sign.
We discovered user enumeration - We found an endpoint that confirms if any email or username has a Lovense account:

https://apps2.lovense.com/wear/getUserInfo?email=[email_or_username]

If the account exists, it returns: {"result":true,"code":0,"message":"{\"test\":\"0\",\"model\":\"0\",\"userId\":\"1564062\"}"}

If it doesn't exist: {"result":false,"code":10001,"message":"account not exist!"}

This endpoint is publicly accessible, allowing anyone to verify if an email or username is registered with Lovense. They even expose the internal userId in the response.
We know exactly how many users are at risk - Notice the userId in that response? They're sequential and incrementing. By creating new accounts and checking their IDs, we confirmed there are 11,367,391 registered accounts as of July 28, 2025, 5:23 PM. That's over 11 million users whose emails can still be harvested through the XMPP vulnerability.
Their "fix" for the email leak was useless - After we suggested the proxy solution, Lovense did implement what they called a "fix" for the email disclosure in mid-July - but it was just another band-aid. They forced users to update by sending 1-2 notifications per day warning that the app would stop working. After the update deadline, they changed something in the XMPP connection to verify it's the official Lovense app connecting.

But this didn't fix the email leak at all. The verification is client-side and can be bypassed by reverse engineering the app. I've already written a Frida script that hooks into the app's XMPP connection to send roster requests and extract emails. With enough research, it's definitely possible to connect to the XMPP server outside the app entirely. Their "fix" just made it slightly more annoying for researchers while doing nothing to actually protect user emails.
Security by obscurity is their strategy - Their security model is fundamentally broken. When you generate a gtoken (auth token), the API returns session-specific encryption keys:

{
  "gtoken": "YJ8J-xCEszM2lPRRJP0jJw...",
  "x": "Dyn42e0dc6ee38c8",
  "y": "FAC4039E5EB8E5BA"
}

The client uses these x/y keys to decrypt "protected" API responses using AES-CBC. They think obscuring API responses this way provides security, but it doesn't - you already have the decryption keys from your own gtoken response! Any authenticated user can decrypt these "secured" endpoints.

They also hardcode encryption secrets directly in their apps. This isn't security - it's theater. Real security would mean fixing the actual vulnerabilities, not hiding them behind client-side encryption that every user can bypass with their own keys or by extracting hardcoded secrets from the app.

What This Means

This isn't just tech bugs. It's about:

Privacy: Every user's email can be exposed
Security: Account takeover affected everyone including admins
Trust: They kept saying it was fixed when it wasn't
Priorities: Old app support > user security

If You Use Lovense

Your email can be leaked just from your username/userid - watch out cam models and toy lovers
Use a throwaway email for the service
Think about if you trust a company that takes 4+ months to half-fix critical bugs

To Lovense: Your users deserve better. Stop putting old app support over security. Actually fix things. And test your fixes before saying they work.

Update (2025-07-29) - It Gets Worse

So after I posted this on Twitter, someone called @Krissy hit me up with some wild news. Turns out they found the EXACT SAME account takeover bug I did... except they found it back in September 2023. Almost two years ago, with their friend @SkeletalDemise. They also found out the endpoint that was susceptible to the account takeover took Usernames as well.

But wait, it gets better. They also found an HTTP endpoint:

/api/getUserNameByEmailV2

This thing let you convert ANY email to username and vice versa. No XMPP dancing required - just a simple API call. Way easier than our convoluted method.

The Timeline That'll Make You Angry

September 4, 2023: @Krissy reports the same account takeover and the other email Vulnerability (http one) to Lovense on HackerOne. Gets triaged as High severity initially.

September 28, 2023: They claim it's "fixed" and mark it resolved, they then asked Krissy to check if it was Fixed.

Same Day: The fix was bullshit. @Krissy immediately retested. They found the vulnerabilities still worked fine. She told them that and then gets ignored.

Same Day: Here's where it gets sketchy. Lovense says "I'd like to make it medium severity, would you agree with this?" Then immediately downgrades it from High to Medium and pays out $350 for both Vulnerabilities. Their excuse? "These PC apps are deprecated, very few cam users still use them."

August 2024: @Krissy asks for disclosure. They ignore her and close it as "resolved."

Early 2025: The Http Endpoint for converting emails/usernames stopped functioning and was patched, without her being informed and after lying about it being patched in 2023.

March 2025: Eva, Rebane and I report the exact same account takeover bug that was supposedly "fixed" in 2023. But here's the kicker - when we pushed for it to be Critical, they actually listened and paid us $3,000 total.

July 2025: Still not properly fixed, still generates tokens but they dont work on most endpoints.

Just now: @Krissy wrote on the HackerOne post for the bounty to be re-evaluated since we got paid way more for the same bug they "fixed" in 2023.

So let me get this straight - they had nearly two years to fix a critical account takeover bug and just... didn't? They told the first researcher it was fixed when it wasnt, then when we reported the same bug again, suddenly it was news to them? And they'll pay $3,000 and upgrade the report to critical for some researchers but only $350 for others finding the exact same bug?

I was able to confirm this is all real because @Krissy added me as a collaborator on their original HackerOne report. The evidence is right there.

The pattern of ignoring security researchers goes back even further - to 2022. Panther found the same XMPP email reveal thing we did, and they got ignored when reporting it. (They reached out to me after publishing this and told me they made a mistake; it was in 2022 not 2018 and provided proof)

[Updated July 31st] Another Researcher Comes Forward

After VX-Underground covered this story, they shared with me a screenshot of @postypoo who DM'd them claiming they found both bugs over 1.5 years ago and were offered 2 free sex toys as a "reward" - which they accepted for the lols:

Screenshot of DM to VX-Underground about finding the same Lovense bugs 1.5 years ago
Screenshot shared by VX-Underground from @postypoo's DM

This person was "flabbergasted it's still not fixed." Yet another researcher who found these vulnerabilities and was ignored. The pattern continues.

[Updated August 4th] Lovense has actually known about the email XMPP vulnerability since 2017

Pentest Partners reported the same vulnerability, as well as the fact that chat data was not encrypted in 2017.

https://www.pentestpartners.com/security-blog/compromising-unencrypted-butt-plug-comms/

What This Really Shows

This isn't just about bad security practices anymore. This is about a company that:

Lies to researchers about fixing critical bugs
Downgrades severity right before payout to save money
Treats researchers differently (most likely based on popularity, as we had eva on our side) - some get upgrades, others get downgrades
Ignores problems for years hoping they'll go away
Repeats the same pattern with multiple researchers

When you find the same critical bug twice, two years apart, with the company claiming it's "fixed" both times... that's not incompetence. That's negligence.

This kind of behavior doesn't just harm users - it actively undermines the security research community. When companies lie about fixes, manipulate severity ratings for financial gain, and treat researchers inconsistently, it discourages responsible disclosure. Why would researchers bother reporting vulnerabilities privately when they might get lied to, underpaid, and ignored for years? Lovense's pattern here is exactly how you push researchers toward public disclosure or worse - selling vulnerabilities on gray markets instead of reporting them responsibly.

Update (2025-07-29) - Lovense's Response: More Lies to the Press

Lovense hasn't commented on my blog post directly, but they're now lying to journalists. Here's what they told Lawrence Abrams from BleepingComputer - and why it's complete bullshit:

Lie #1: "Fixed by end of June"

They claim the email vulnerability was "fully fixed by the end of June 2025." This is a complete lie. It still works perfectly. The XMPP server still leaks emails exactly as described in my original report.

Lie #2: Misrepresenting My Research

proof

They claim I said you need someone to "accept a friend request" to get their email. I never said that anywhere. Look at my actual HackerOne report - the attack works without any friend request acceptance. They're literally making up quotes to discredit the research.

This is their strategy: lie to journalists, misrepresent the research, and hope nobody checks.

The vulnerability still works today. They can lie to the press all they want - the technical evidence speaks for itself. (This was true at the time of writing - see below for when it was finally fixed)

Update (2025-07-30) - Lovense Tries to Silence Me

After publishing this blog post, Lovense is now trying to get me banned from HackerOne for "unauthorized disclosure." This is despite them explicitly telling me TWICE that I could publish:

On May 30, 2025, I warned them:

"Given the severity of these issues and the lack of response or mitigation, we intend to publish our findings in one month, regardless of whether the vulnerabilities are addressed by then."

In their response on June 4, 2025, they said:

"We also understand that you may be considering publishing a write-up or sharing your findings related to these vulnerabilities. While we fully respect your decision, could you kindly let us know which platform or channel you plan to use for publication?"

On June 14, 2025, I confirmed:

"As previously planned, we will proceed with publishing our findings in one month, sometime in July, on our security research blog."

On June 17, 2025, they explicitly acknowledged this:

"We respect your decision to publish your findings and appreciate your commitment to transparency. If you're open to it, we'd be grateful for a chance to see the write-up before it goes live — just to ensure our latest updates and response are accurately reflected. In any case, we'd love to follow your work, so please feel free to share a link to your security blog for our reference."

They even asked to follow my work and wanted a link to my security blog!

Now they're claiming to HackerOne that my disclosure "violates HackerOne's Code of Conduct" and demanding I take down all public mentions within 48 hours or face a permanent ban.

This is classic intimidation tactics. I gave them 30 days notice on May 30th, but didn't actually publish until July 28th - almost 2 months. They explicitly acknowledged my plans to publish, asked to see the write-up if I was open to it, and even wanted to follow my security blog. Now they're weaponizing HackerOne's platform to try to shut me up.

The vulnerabilities are still not fixed. The email leak still works. And now they're more interested in silencing researchers than protecting their users. (At the time of writing it still worked, read till the end for fix update)

Update: HackerOne is Siding with Lovense currently

After showing HackerOne the emails where Lovense explicitly gave permission, they responded with this creative interpretation:

"It appears there was a miscommunication about the disclosure process. When the program stated 'we'd be grateful for a chance to see the write-up before it goes live,' they were requesting to review your content prior to public disclosure, not granting permission for immediate publication."

"The statement 'We respect your decision to publish your findings' was acknowledging your right to eventually publish, while still expecting coordination with them first."

So according to HackerOne:

"If you're open to it" = mandatory requirement
"We respect your decision" = don't you dare do it yet
"We'd be grateful" = you must comply

They're literally rewriting plain English to protect Lovense. When someone says "we respect your decision to publish" after you tell them you're publishing in July, that's acknowledgment, not a hidden requirement for pre-approval.

HackerOne also claimed publishing "potentially puts users at risk." The opposite is true - Lovense is actively lying to users that the vulnerability is fixed. Users think their emails are safe when they're not. That's the real risk.

Four months. Still not fixed. Still lying about it. And they've been ignoring this same vulnerability since at least 2022 when other researchers reported it - though they likely knew about it even earlier given how obvious the flaw is in their own code. But somehow I'm the problem for telling the truth.

Update (2025-07-30) - Both Vulnerabilities Finally Fixed After Public Pressure

After publishing this post, something incredible happened. Both critical vulnerabilities were suddenly fixed within 2 days.

Email Disclosure - Fixed

The XMPP email disclosure vulnerability that they claimed would take 14 months to fix? Fixed in 2 days.

Remember - they told us in June they had a 1-month fix ready but chose the 14-month approach for "legacy support." After we pushed back, they agreed to implement fixes faster and gave us deadlines (June 19 and July 3), but those came and went with nothing actually fixed.

They finally removed all email-based JIDs from their XMPP server. They already had internal user IDs (ofId) but were maintaining both systems. Now:

Before: Login with email!!!domain.com_w as username, roster entries like [email protected]
Now: Login with internal user ID like aafbbb3d112640c2bb52aa78b4886brhcs9u0fdua7r8ntpe8rmbtu, roster entries like aafbbb3d112640c2bb52aa78b4886brhcs9u0fdua7r8ntpe8rmbtu@im.lovense.com

This now correctly shows that users login with just the user ID (without the @im.lovense.com part), and then the roster entries have the full JID format.

Account Takeover - Fully Fixed

The /api/connect/genGtoken endpoint now returns a 404 error - completely removed.

The fix timeline:

September 2023: First reported by @Krissy
June 2025: Partially "fixed" - endpoints reject tokens but generation still worked
July 30, 2025: Finally fully fixed - endpoint removed entirely

The Truth About These "Fixes"

Email Disclosure: First reported by Panther in 2022, took 3+ years
Account Takeover: First reported by @Krissy in September 2023, took nearly 2 years
They knew this was broken from day one: When implementing XMPP, they chose to use real emails as Jabber IDs (JIDs). This is XMPP 101 - anyone who's ever set up an XMPP server knows JIDs are visible to all contacts. They deliberately built their entire chat architecture on exposing the exact data they should have been protecting.
They admitted having a 1-month fix ready but initially chose 14 months for "legacy support"
After we pushed back, they agreed user security takes priority and promised to implement the 1-month fix
They gave us deadlines (June 19 and July 3) but missed them completely
They lied to journalists saying it was already fixed
They tried to silence me with legal threats

But 2 days after public exposure? Both suddenly fixed.

This proves they could have protected their 11+ million users at any time. They just didn't care until forced.

Thanks to eva and Rebane for helping with the research, and RenderMan from Internet of Dongs for the disclosure help.

Speaking of Internet of Dongs - they actually found similar email vulnerabilities in Lovense back in 2016. That's right - nearly a decade ago.

According to their published vulnerability reports:

DVE-2016-01: User email enumeration through the /ajaxCheckEmailOrUserIdRegisted endpoint - the same endpoint we used in our attack chain
DVE-2016-02: Email addresses exposed in the "Marketplace" feature responses - users' emails included in API responses but not displayed in the app
DVE-2016-03: Another email enumeration vulnerability through the /getAppNotifications endpoint

All reported to Lovense in November 2016.

Ok I'm done now, thanks for coming to my Ted Talk

Update (2025-08-02)

Apparently I am not done, one guy came to me on twitter and dmed me with this message

He also said to me later that he's seen it happening since 2022

I did some research and I discovered the API to get a models wishlist when they send you the link, had populations like address, email, name and phone. So these fields used to be populated up until recently, unacceptable honestly.

I think this person had someone use the exploit on them (post on /r/CamGirlProblems)

Also another user replied on my Twitter post, yet another way emails were exposed:

They confirm you could literally just open a file explorer like Filza and read the emails of everyone you communicated with on Lovense. The emails were stored in plain text in local files.

Lastly here is the CEO of Lovense's response. I think its disgusting:
https://www.documentcloud.org/documents/26038431-lovense-dan-liu-response/

Im done fr this time. May the Force be with you.

Update (2025-08-04)

One more thing, on July 31st they also published a Notice, which is required legally in many Countries, including all of the EU.

You have to make sure it gets to your customers, yet they hid it in their press room.

https://www.lovense.com/vulnerabilities-fixed-announcement

Firstly they say "Under specific conditions, account email addresses could be exposed."

There were no specific conditions all you needed to know was their account username/userid.

They then go on to say "Following a thorough review, as of today, there is no evidence indicating that any user data has been accessed or misused." which is not true

Someone informed me that osint.industries have been using the vulnerabilities, until they got patched.

Other osint sites have had Lovense modules

One example of that is:
https://osint.lolarchiver.com/

screenshot showing lovense module

Another example is:
https://www.predictagraph.com/