Matt Palmer

Last week, we launched Replit Agent, our AI system that can create and deploy applications. Now, with only a few sentences and a few minutes, you can take an application from idea to deployment.

You can think about the Agent like a pair programmer. It configures your development environment, installs dependencies, and executes code. From your laptop or the Replit mobile app, the Agent is changing how our users build software.

If you'd like to learn more, we've compiled some of our favorite examples, tutorials, and articles on the agent so far. 

Introducing Replit Agent

The Replit Team

Earlier today, we emailed users about a security vulnerability affecting parts of our single-sign-on functionality. While we’ve fixed the vulnerability and have found no evidence of any exploit, we are publishing this post out of transparency.

On Tuesday, June 6, while auditing our authentication systems, we investigated a possible vulnerability related to our single-sign-on functionality. We patched the vulnerability the same day and proceeded to investigate whether any users could’ve been affected by it.

On Thursday, June 8, we identified a subset of users who had previously used our single-sign-on functionality and were potentially exposed to this vulnerability. In particular, if the email address on record for a user’s Replit account was not already tied to a GitHub account, an attacker could have created a GitHub account by re-using the email address on record for the user’s Replit account. Under certain conditions, it would have been possible to use that fraudulent GitHub account to impersonate the affected user on Replit. While we have no evidence that a third party logged into any Replit account this way, out of caution, we have logged out of all Replit sessions all users who we could identify as potentially fitting these criteria.

Additionally, out of an abundance of caution, we have logged out all users who have ever used our single-sign-on functionality with a GitHub, Facebook, or Apple account.

We take the security of our users' accounts seriously. We continuously perform security audits and, when we discover issues, we proactively address them and harden related systems. In the coming months, we will continue to make substantial improvements to our authentication systems to make them more secure and user-friendly.

If you are experiencing trouble logging back into your account or have additional questions, please reach out to support.

June 6, 2023, Single-Sign-On Security Vulnerability

J Malcolm

Replit gives you the power to both build your own applications and to leverage powerful third party services through their APIs. By integrating third party services into their Repls, Replit users have unlocked a diverse range of capabilities such as speech to text, video livestreaming, embedding data into AI applications, and even tracking Amtrak trains.

Integrating a third-party service into your Repl usually involves acquiring an API key or token from the third party that uniquely identifies you and your app. It’s important to keep this API key secret because if it is leaked and used by someone else, they could misuse it while impersonating you. You could find yourself losing your API access, or even incurring unauthorized charges.

We saw this need and developed tooling around it for you. Replit makes it easy for you to protect your API keys, by using Secrets. When you add your API key as a Secret, you make sure that it won’t be visible to others who view your Repl’s code, and won’t be included if anyone else forks your Repl.



With the recent explosion of interest in AI, there has been a corresponding rise in the theft of OpenAI API keys in particular. Replit is doing its part to make sure that our users don’t become victims of this crime. We have been a partner of OpenAI’s since 2021 and care deeply about AI development and security.

Keeping Your API Keys Safe

Luis Héctor Chávez

Yesterday, on April 2, 2023, Replit discovered a site vulnerability that may have exposed GitHub auth tokens for <0.01% of Replit users, stemming from use of the GitHub import feature. This could have permitted unauthorized read/write access to all the repositories of those users by default (users can choose to authorize just a subset of repositories).

We have no indication that those exposed tokens were misused or used to exploit GitHub repositories.

The vulnerability has been fixed, all existing GitHub auth tokens associated with the Replit app have been revoked, and access to the GitHub import feature has been restored.

The number of exposed users was limited to <0.01% because there are two preconditions that needed to be met for a user’s Repl to be vulnerable:

The Repl was created using the GitHub import feature; and

One of: 

April 2 Potential GitHub Credentials Exposure

Escaping Dirty Pipe Cover

You may have heard that there was a very critical Linux kernel vulnerability making the rounds. As with all important enough vulnerabilities, this one has a catchy name: Dirty Pipe (no logo, though). This blogpost attempts to explain how that vulnerability impacted Replit. The good news is that as far as we know, there weren't any successful exploitations of it!

That article linked above has the full explanation and is definitely worth the read because it narrates the journey from discovery to fix. In case you're in a hurry, the short description of that vulnerability is that it allowed any user to temporarily overwrite any file in the filesystem, without requiring any write permissions to do so. Temporarily because it didn't actually change the file, just the in-memory page cache, so if the kernel was under any sort of memory pressure, those changes would go away. There were a few more restrictions (mostly about the position, alignment, and length of the write), but other than that this allowed the attacker to make all sorts of very scary modifications to the system. Notably, the proof-of-concept code allowed any user to open a root shell by overwriting a setuid binary that had privileges to "become" root by the mere act of invoking it.

The moment our "security advocate" (in reality it's just one of our platform engineers in a funny disguise until we hire a full-time security engineer) realized that this was such a serious bug, we immediately tried the proof-of-concept code. And we were delighted that it didn't work! We very recently enabled the no new privs bit that negated the effects of the setuid bit, so the user was greeted with a normal shell instead of a root shell. This meant that the scariest part of this exploit (escalation of privileges) was not possible in our system. Furthermore, the container has a very limited set of capabilities, which meant that even if the root shell would have indeed been possible, the attacker would not have been able to make most changes to the system. Hooray for defense in depth!

Our initial happiness quickly dissipated, though. Even if the proof-of-concept didn't quite work all the way, it still had an effect: the files were still rewritten. So what's the worse that an attacker could do with that newly found power? Since we use Linux containers (through Docker), that means that the files in the root filesystem are shared in read-only fashion among all the containers in a system. So what if we tried to overwrite an important binary that everybody used (say, /bin/sh)? Turns out that the page cache is shared among containers too, so the modifications were visible to all repls in that one machine! This means that if a malicious user wanted, they could have been able to surreptitiously make changes to the shell, which means that they could make any modifications to any repl that happened to be running in that same machine. Exfiltration of secrets, modification of files, anything. So we needed to patch this ASAP.

Fortunately the kernel already had a patch available, so all we needed to do was to make a deployment and wait a bit. We got very lucky here, because this could be a very long battle to get mitigations in place, but the disclosure of this was well-coordinated. We were very happy that this moment was mostly anti-climactic.

By the way, if you tried to open any C# repl between 2022-03-09 and 2022-03-11, you might have seen a warning about a kernel bug preventing those repls from running. It turns out that it's a different, unrelated issue. Two different kernel bugs in the same week? What are the odds!? But that's a story for another day.

June 6, 2023, Single-Sign-On Security Vulnerability

Keeping Your API Keys Safe

April 2 Potential GitHub Credentials Exposure

Escaping Dirty Pipe (a.k.a. CVE-2022-0847), mostly unscathed