Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.duckybot.xyz/llms.txt

Use this file to discover all available pages before exploring further.

This incident has been fully resolved and the effects have been reverted.
This blog post is an in-depth and detailed explanation of the security incident that occurred on May 13th, 2026 involving the unauthorized access and management of a few in-game ERLC private servers. An investigation was launched as soon as we were notified and information has been gathered by the Development team in order to write this blog post for the sake of transparency.

​
What was the exploit, and why did it work?

The exploit rooted from an issue with our latest version of ERLua, which is the ERLC API wrapper and library used by Ducky, written in Lua for the Luvit runtime. This library is developed by the same people that develop Ducky. ERLua is built on a TTL caching system, where server information is only fetched when needed, and at a minimum period of 15 seconds. For example, if the application requests the server’s information from ERLua, ERLua will check its cache for private server data fetched within the TTL (15 seconds). If data is found, meaning it has been requested directly from PRC’s API in the past 15 seconds, ERLua responds to the application’s request with the cached data. Otherwise, if no data has been fetched, or if the cached data is older than 15 seconds (and is therefore considered “expired”), an attempt will be made to fetch server data directly from the PRC API. That data is then cached and stored for another 15 seconds. To help you better understand the following section, here’s a brief diagram of how an ERLC API key is structured. The API key pictured below is composed of completely random characters for pure demonstration and is not valid in any way. API Key Structure The only issue with this was nothing involving the concept, rather it was how they were indexed. ERLua operates on a centralized Client which manages every Server and inbound requests from the application. When an application wants a server’s data, it makes a request to the Client with the server key. The Client then searches for a Server that matches the key provided by the application. This is where the issue lies; the Client strips the first part of the key to isolate the server ID and looks for a Server in its list of managed servers with a matching ID. It never references the key again to ensure the first part is actually valid. This only worked with keys that were already cached, though, meaning the server had to have their key actively linked with Ducky. This behavior was implemented as part of an update to ERLua that implemented support for PRC’s recent addition of Event Webhooks. We changed the way API keys are validated internally within ERLua without proper thought, and this was an oversight on our part. We’ve updated the system to properly validate the API key before returning a Server to the application. This exploit has actually been possible for months, however it was only discovered a few days ago due to an increase in activity by ERLC “raiding groups” who use Roblox exploits to intercept and read data sent to the Roblox Player Client that usually isn’t seen by the normal player. A malicious actor created a website that makes it incredibly easy to access this data, which allows for anyone to view the assets and settings of the private server they join, which includes livery IDs, uniform IDs, server settings, and server IDs.
This incident did not directly expose full ERLC API keys of any server, however it is recommended you still regenerate your API keys as an extra safety measure.

​
Timeline

May 11th, 2026 @ 11:04 AM EDT — Initial Exploit Discovery

An individual, suspected to be part of a larger group of “leakers” in a community named “ERLC Leaks”, discovered an exploit that allowed anyone to link Ducky to an ERLC server with just their Server ID. This granted them the ability to view live server statistics, including players in-game, vehicles, modcalls, emergency calls, kill logs, command logs, etc. This also allowed them to execute commands via Remote Server Management.The exploit did not directly expose server API keys, meaning if they wanted to do something to the server, they would have to use Ducky’s commands, which are fully logged and occasionally monitored.It is believed that this individual discovered this exploit accidentally, out of pure curiosity due to an unrelated and general leak of ERLC Server IDs (known internally as the server’s UniqueKey, an identifer that on its own cannot be used to access the PRC API). They input the Server ID into Ducky’s configuration, and Ducky unexpectedly accepted it.The individual only executed about 5 commands in total, and none were of significant damage. Only the :m and :shutdown commands were used.

May 13th, 2026 @ 12:55 PM EDT — Exploit Privately Shared

The individual resumed actions and continued to abuse the exploit for another 10 minutes. This time, they shared the exploit with others, who also begun to abuse the exploit.Once again, however, only the :m and :shutdown commands were used, and therefore no significant damage was caused.

May 13th, 2026 @ 1:28 PM EDT — Exploit Reported

A separate individual opened a Development ticket via Ducky’s Pond to report the exploit to us. This user was part of the “ERLC Leaks” team.The reporting individual spent a few minutes collecting information to provide us.

May 13th, 2026 @ 1:39 PM EDT — Exploit Identified

We identified the exploit after communicating with the reporting individual and clarifying what they were reporting. Attention was immediately shifted to this incident.

May 13th, 2026 @ 1:41 PM EDT — Exploit Published

The group of malicious actors under the name “ERLC Leaks” published the exploit in their community server.Luckily, we were already in the process of deploying the fix, which was completed in less than 60 seconds after the published message was sent.

May 13th, 2026 @ 1:42 PM EDT — Exploit Patched

The bot was restarted to deploy the fix.We fully patched the exploit approximately 3 minutes after it was properly reported.

May 13th, 2026 @ 1:42 PM EDT — Effects Identified

We immediately began taking steps to identify the surface-level effects with quick log searches, as well as all individuals who were involved in the abuse of this exploit.We then proceeded to search configuration logs to search for deeper attacks using the API key, such as Automations or ban syncing events. No such activity was detected.

May 13th, 2026 @ 1:45 PM EDT — Security Improvements

Additional security measures were deployed to the way our system handles ERLC API keys in order to prevent similar incidents in the future.

May 13th, 2026 @ 1:48 PM EDT — Incident Resolved

The incident was fully resolved and all significant effects were properly reverted.No API keys were exposed, however we requested for all servers that were identified to be affected to regenerate their ERLC API key. It is recommended you do the same for your server, even if you were not contacted.All involved individuals have been permanently blacklisted from Ducky for violations of our Terms of Service.
Last modified on May 13, 2026