Blog: Internet Of Things

A smart sex toy that pings your employer?

David Lodge 12 Feb 2018

Whilst checking that another vulnerability in a smart sex toy had been fixed, we discovered something more concerning. The device in question was geared towards adult webcam models/performers. We discovered that cam models using the app could be inadvertently unmasked, flagging their online activities to employers and others they may not want to share this information with.

Some cam models wouldn’t be concerned about this. However, those for whom modelling was a part-time activity and had other employment may be alarmed to know that their sex toy could inadvertently inform their employer.

A related vulnerability allowed remote hijack of the toy over the public internet.

Fortunately, the vendor involved responded promptly and effectively to responsible disclosure. The ‘ping’ issue is now fixed in the latest version of the app.

We are not here to kink-shame or pass judgement on those who use smart sex toys. In a modern society people should be able to use smart sex toys if they wish to do so, without fear of their data or habits being inadvertently exposed to others.

A positive outcome: unlike many smart sex toy vendors, Lovense responded quickly when we reached out to them. They quickly fixed the bug; a positive model for other vendors to follow.

The vulnerability

The Lovense Connect app makes regular outbound requests for an API server at ‘ A ‘ping’ or heartbeat of sorts if you like, even if the app is running in the background. Any user of the same network (assuming no client segregation) can see these requests and deduce that the user has the app installed. That means that, for example, other users of the same Wi-Fi network (maybe friends and relatives?) can work out that the user is a cam model.

Here’s the request:

POST /app/lan/setInfo HTTP/1.1

Content-Type: application/json; charset=utf-8

Content-Length: 169


Connection: close

If the user has another employment in addition to cam modelling and uses the same smartphone for email, social networking also, then taking that phone to their work place could cause significant problems. Just connecting the mobile device to their employers wireless network will result in requests for a Lovense site being made through it.

This may trigger content filters, potentially resulting in an investigation by the IT team. ‘Why was a request to a sex toy server being made from our wireless network?’

Here’s how a cam model would use the app

The smart sex toy connects to their smartphone, which uses the app to talk to the Lovense API via the internet. As their customer has the app as well (or is using a web browser) the model can give permission to the client to take control of the the sex toy, usually on payment of a tip.

Here’s how it could go very wrong for the cam model

The cam model takes their smartphone to their work place the following day. They don’t take their sex toy with them to work, but that doesn’t matter. The app is still running in the background (who remembers to close apps fully?). Their phone connects to the wireless network at the office and automatically makes requests for the API at even though the user isn’t using the app!

These requests will undoubtedly trigger content filters, which IT staff then investigate

That could make for a VERY awkward discussion between the employee and the employer.

The same issue can be used to remotely hijack a cam model’s adult toy, either on the same local network (in the case of iOS) or from any point on the internet (in the case of Android).

Hijacking the smart sex toy

The app works by creating a local web server on the mobile device, which is unauthenticated and can be connected to by any user with network access to the device, such as being on the same wireless network or perhaps even on the cellular network.

Accept-Encoding: gzip, deflate


User-Agent: okhttp/3.8.1


This identifies the IP address of the device ( on the above sample wireless network) and two TCP ports:

  • 34567 – HTTP and websocket server
  • 34568 – HTTPS and websocket server

There are a number of calls supported to the web server to read information, or to control a connected toy. The simplest is GetToys which will return a list of toys that the user has:


So now we can see that the user has a Lovense Hush smart butt plug

Now we can take control of the toy as we’re on the same local network and simply issue commands to the web server (we’ve done that before), and there’s a good resource here from the awesome Kyle Machulis (@qDot).

Remote sex toy hijack

We noticed that the Android version of the app returned the CORS Access-Control-Allow-Origin header on responses. This header instructs a web browser to redefine the Same Site Origin policy that restricts scripts from reading data from the remote website.

HTTP/1.1 200 OK

Connection: Keep-Alive

Access-Control-Allow-Origin: *

Content-Length: 36

Content-Type: text/html; charset=utf-8

This means that an attacker could scan the user’s local network for toys from the Internet and take control. This requires anyone on that local network (e.g. their home wifi network) to visit a rogue web site, probably by phishing or IM. Then we can exploit the CORS issue, as shown below:

Now we have remote control over the toy. Fail!

The iOS client did not return this header and thus was only vulnerable from the local network. Only the Android version had this issue

Resolving these security flaws

Creating a local, unauthenticated web server on the mobile device is a design flaw that was relatively difficult to resolve without a complete redesign.

We understand that Lovense instead rewrote the application to disable the ‘ping’ from the mobile app if it was not currently connected to a sex toy. That was an effective workaround the problem, although does not stop a port scan being used to discover the web server. Enumeration and remote control/hijack is therefore still possible. We think this is a less serious issue though

The CORS issue was relatively simple to resolve, preventing the remote hijack problem with the Android version of the app.

Hence, updating the app to the latest version resolves the issue.

Temporary mitigation

The simplest mitigation is for users to close the app completely when it is not in use. This will prevent the ‘ping’ being sent to Lovense servers.

Separately, it would be wise for cam models to use a dedicated mobile device that is not used for any other online activities.

Risk factors

Is this a likely attack vector? I hope not; I do not know how many cam models also have other employment.

However, the consequence for even one cam model being unmasked in an uncontrolled, unmanaged fashion through this security flaw could be significant.

However, we accept that it is perfectly possible for the cam model’s client to unmask them directly through the online modelling session, should they wish. It’s worth noting that the client may be unmasking themselves as a cam model client at the same time, so perhaps there is less of an incentive to do so.

Some people are squeamish or easily offended regarding sex related topics, so models may be fired, harassed, assaulted, and if publicly outed, shamed to co-workers, family or friends. No-one deserves to have that happen.


Lovense should be given credit for responding to and resolving this issue quickly. This shows an organisation that is increasing its maturity in terms of security.

We were assisted by @internetofdongs with the disclosure process and strongly encourage others to do the same. Coordinating research in to this fascinating area of security is a wise idea, as it avoids duplication of effort as we have seen others do of late.