OAuth authorization auto-approval incident disclosure


On March 26th, between 00:57am and 11:17am UTC [timezone converter], our API’s OAuth approval form meant for users to review and approve or deny granting permissions to third-party applications (e.g. an author support platform, some Wordpress theme/plugin purchase confirmation mechanisms, etc.) was set on auto-approve, potentially causing users to grant some API access permissions to a third-party application when they didn’t intend to.

We’ll be sending an email shortly to all affected users, including the details of which permissions were granted to which application.

This issue was resolved once identified and we did not observe any exploitation nor was anyone’s information leaked publicly. We revoked all the access tokens granted during the incident shortly after fixing the issue.

We sincerely apologize for this. We take security very seriously at Envato and this incident is not something we take lightly. We have conducted a formal Post-Incident Review and we are taking measures to ensure this kind of incident isn’t likely to reoccur.


OAuth is the protocol behind the “Sign in with Facebook/Twitter/Google” buttons you see in many places on the Internet. A third-party application (client) sends users (you) to an authorization form (a page with a list of permissions and Approve and Deny buttons) for a platform (here Envato, in other cases Google, Facebook, etc.). If you’re not signed in on the platform yet, it asks you to sign in first, and only then shows you the form. Under normal circumstances, the form looks like this:

If you click “Approve”, it sends the third-party app a code that lets it access specific information and perform operations on your behalf on the platform (in this case, make API requests as if they were you, accessing your information via our API). The form lists all the permissions you’ll be granting (e.g. access username, purchase history, etc.) and they can only perform those specific operations and get that specific data.

Do you have an example?

Some authors have a third-party support application for buyers to submit support requests. They use the feature described above to authenticate buyers of their items. They send you to our authorization form, you sign in with us, review the list of permissions that includes access to your Envato username, email and purchase history. If you approve it, the author’s app can check that you did indeed buy their item.

Another common use is for Wordpress theme or plugin purchase verification or auto-update. When you install some themes, they ask you to “verify” the purchase by sending you to our OAuth authorization form. When you click Approve, the theme can make a call to our API to check the purchase history of your Envato account and verify that you did purchase the theme and then unlock some features (like automatic upgrades).

Please note that this is different from API Personal Tokens. Most theme/plugin auto-update systems use an API Personal Token instead of OAuth, and Personal Tokens weren’t affected by this. But some use OAuth and their users may have been impacted by this if they went through the registration process it during the incident.

So what was wrong?

During the incident, for about 10 hours, this form would auto-approve. Any user sent to it would be asked to sign in to Envato, then once they did, they would just see a flash of the form and the third-party app would get access automatically. If you were going to grant access anyway that’s not a problem, but if you wanted to deny the access, then you didn’t get the chance.

How do I know if I was affected?

If you’ve been affected, you will receive an email shortly, to the email address associated with your Envato account, with the details of which permissions were granted, and to which application.

You would only have been affected if you clicked a link to an Envato OAuth authorization form on March 26th, between 00:57 and 11:17am UTC, and you signed in with Envato, or were already signed in.

This issue could not be used to gather just anyone’s data; each user needed to be signed in and click the appropriate link directing them to authorise the application.

What kind of data access was granted?

Each third-party app has a custom scope of permissions they ask to access. Permissions are things like “access user’s username” or “access their purchase history for items authored by the creator of the third-party app”. They’re encouraged to ask for as little permission as they need to perform their purpose, and they know that asking too many permissions may discourage users from using their app under normal circumstances. Affected users will receive a summary of the specific permissions granted during the incident.

No password, credit card or banking information was made available.

How many people were affected?

During the incident, 2,292 access tokens were granted by the OAuth authorization form in total, spread over 1,158 individual user accounts and 204 third-party apps. A subset of those are people who had already granted the same permissions to the same app before the incident.

Was this exploited in any way?

Based on the authorization pattern during the incident, we are confident that we noticed and fixed it before anyone outside of our development team observed the flaw or exploited it. If a third-party application gathered data you didn’t intend to share, it was likely in good faith and without realising there had been anything wrong with the authorization process.

Was my data publicly leaked?

No. Even if you were sent to a form during the incident, access to the data was only granted to the very specific application that sent you to that form, owned by an Envato community member who has agreed to specific OAuth terms.

Do they still have access?

No, we revoked all the access tokens granted during the incident shortly after fixing the issue. But it is possible that the application accessed and stored some of that data while it had access to it. Since it doesn’t seem that anyone found out about the issue before we did, the app would most likely have just have accessed and stored the data it automatically accesses and stores under normal circumstances to perform its usual purpose (e.g. verify that you purchased a specific item).

What should I do?

If you’re one of the users who went through the form while it was being auto-approved, you’ll receive a separate email to the address of your Envato account, containing a list of the applications and permissions that were granted in relation to your account during the incident. You’ll be able to review the permissions and contact the OAuth application owner to follow up about this and, if you deem it necessary, ask them to delete the data their application gathered about your account.

If you’re the owner of an application using Envato API OAuth, and a user whose permissions were granted to your application during the incident contacts you, we ask you to be transparent with them about the data your application gathered and, if they request it, that you delete the data, in agreement with PII laws and our terms.


This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.