Is Crunchyroll Speeder: adjust playback speed [QVI] safe?

Medium risk

Crunchyroll Speeder exchanges your Crunchyroll session cookies for an OAuth token and reads your account, history, and subscription data.

On every crunchyroll.com page the extension reads your 'device_id' session cookie and mints a fresh OAuth Bearer token from Crunchyroll's own /auth/v1/token endpoint. It then uses that token to read account-scoped data well beyond playback speed: your profiles, continue-watching history, and subscription/billing details. The content script is driven by a remote command list fetched from the third-party server me3x.online, and the harvested data is uploaded back to that same server, keyed to a persistent per-install identifier. A 'shareInsights' data-collection toggle defaults to on at install.

Awesome Extensionsv1.0.16Chrome Web Store
45Risk

AI-generated. Findings may contain errors. Those marked Verified have been manually reviewed.

Publishers can request a review.

Findings

SeverityMEDIUM
ClassUNWANTED
TypeUnexpected
CWECWE-522
SourceAI SANDBOX

Trades your Crunchyroll login cookies for an account API token in the background

When you open a Crunchyroll page while logged in, the extension reads your session cookies and mints a fresh access token via Crunchyroll's login endpoint, unprompted.

Observed twice; the token is then used on third-party API calls.

01EvidenceCAUSE EFFECT
What actually happens
You did this

You open a Crunchyroll page while signed in.

No click or opt-in is needed beyond being logged into crunchyroll.com.

The extension did this

The extension reads your session cookies and exchanges them for a Crunchyroll account access token.

It posts your device_id cookie with a cookie-grant flag to Crunchyroll's token endpoint and stores the returned token for later account API calls.

02EvidenceNETWORK CAPTURE
Captured request
POSThttps://www.crunchyroll.com/auth/v1/token
Observed during dynamic analysis: the request auto-fires from the extension content script on navigation to a crunchyroll.com page with a login cookie present, reproduced across two independent runs. The device_id value shown is a planted marker, confirming the value originates from the cookie the extension reads. The endpoint returned an access_token to the extension when a valid session was present.
Headers
Content-Typeapplication/x-www-form-urlencoded
AuthorizationBasic bm9haWhkZXZtXzZpeWcwYThsMHE6
Body
device_id=CANARY_DEVICE_12345&device_type=Chrome&grant_type=etp_rt_cookie
03EvidenceOPAQUE REVEAL
Why you can't catch this in DevTools

The Authorization header on the token request is a Base64 Basic credential. Decoded, it is Crunchyroll's public web-client identifier with an empty password, used to mint a user-scoped token from session cookies. It is a public client identifier, not a private vendor credential.

What's actually being sent
Authorization: Basic noaihdevm_6iyg0a8l0q:
04EvidenceCODE COMPARE
The code that does this

Cookie-to-token exchange and where the resulting token is reused

What it actually does
Token mint from the device_id cookiecrunchyroll.min.js:5898
var getConfigTokens = function() {
    return async function getConfigTokens(profileId) {
        var body = {
            device_id: getDeviceIdFromCookies(),
            device_type: "Chrome",
            grant_type: "etp_rt_cookie"
        };
        if (profileId) {
            body.profile_id = profileId;
            body.grant_type = "refresh_token_profile_id";
        }
        var formData = convertObjectToFormData(body);
        return Request_postRequest(buildTokensUrl(), formData);
    };
}();

var getDeviceIdFromCookies = function() {
    return getCookie("device_id") || parseCookies().device_id;
};

var buildTokensUrl = function() {
    return "".concat(MAIN_URL, "/auth/v1/token");
};
Basic credential on the mint, Bearer credential on subsequent account readscrunchyroll.min.js:5003
// postRequest (token mint) -> crunchyroll.min.js:5003
options = {
    headers: {
        Authorization: "Basic bm9haWhkZXZtXzZpeWcwYThsMHE6", // noaihdevm_6iyg0a8l0q:
        "Content-Type": "application/x-www-form-urlencoded"
    },
    method: "POST",
    body: formData.toString()
};

// getRequest (account API reads) -> crunchyroll.min.js:4943
var token = await getUserToken();
options = {
    headers: {
        Authorization: "Bearer ".concat(token)
    },
    method: "GET"
};
05EvidenceFIELD TABLE
What the token request reads and what the resulting token unlocks
FieldValueWhy it matters
Your Crunchyroll device cookie
device_id=8f3c1a2e-7b40-4d11-9c5a-2e6f0b9d1a44The device_id cookie set by your Crunchyroll login is read and used as the basis for minting the token.
Logged-in state
ajs_user_id present (logged in)The extension detects you are signed in before minting, so the token reflects your account.
Account access token
access_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...The returned Bearer token grants read access to your Crunchyroll account profile, watch history, and subscription data.
06EvidencePLAIN NOTE
About the credential used

The Basic credential on the token request decodes to `noaihdevm_6iyg0a8l0q:`, which is Crunchyroll's own public web-client identifier with an empty password. It is not a private credential extracted from Crunchyroll. The finding is that the extension mints and reuses an account-scoped token from your session cookies on its own, separate from any feature you initiated.

Data recipients

me3x.onlinewww.crunchyroll.com
Updated 17 September 2026gdakpfnjkpiakgcicmbbnfpjkdlhamok