Summary
Togoder Security scanned the npm package oauth@0.9.15 on Oct 6, 2026. An AI review of 9 source files produced 7 medium, 6 low severity findings. The overall verdict is medium: the findings flag risky but common patterns (dynamic code, unsafe defaults, broad file or network access) rather than confirmed malware.
Findings 13
Hardcoded session secret
NPS-05F065578075
The Express session middleware is configured with a hardcoded secret ('skjghskdjfhbqigohqdiouk'). This weakens session security and could allow session forgery if the source is exposed.
Open redirect via unsanitized action parameter
NPS-1EF06C7C755E
The 'action' query parameter is used directly in res.redirect() without validation. An attacker could craft a link with an external URL as the action, causing an open redirect after OAuth authorization.
Unvalidated redirect URI and lack of state validation
NPS-1D550CE0D73E
The redirect_uri is hardcoded and the state parameter is static, providing no real CSRF protection. The server does not validate the state parameter on callback, allowing potential CSRF attacks. Additionally, the code does not verify that the redirect_uri matches the one used in the authorization request.
Potential exposure of access token in HTTP response
NPS-FF1AE271701D
The server responds with the raw access_token in the HTTP response body (res.end(access_token)), which could be logged or exposed to the client. While this is an example, it demonstrates a bad practice of sending sensitive tokens in plaintext responses.
Credential handling in example code
NPS-74BA8639BACC
The file contains empty string placeholders for clientID, clientSecret, and callbackURL, indicating users are expected to hardcode OAuth credentials directly into source code. This promotes insecure credential storage practices and risks accidental credential exposure in version control if users follow this example pattern.
Insecure Random Number Generation
NPS-9F9CE78BF328
The _getNonce function uses Math.random() to generate the OAuth nonce. Math.random() is not cryptographically secure and is predictable. In OAuth, nonces must be unique and cryptographically random to prevent replay attacks. A predictable nonce weakens the security of the signature and could allow an attacker to replay requests or forge signatures.
Potential Credential Leakage via Redirect Following
NPS-190581858483
The _performSecureRequest method follows HTTP redirects (301/302) and resends the same OAuth-signed request (including the Authorization header) to the new location specified by the Location header. This can leak OAuth tokens and secrets to a malicious or compromised redirect target, especially if the redirect goes to a different origin. The followRedirects option is enabled by default.
Insecure OAuth callback URL
NPS-69A56F6BD6BB
The OAuth callback is hardcoded to 'http://localhost:3000/google_cb', which uses HTTP instead of HTTPS. In a production environment this could expose OAuth tokens to interception.
Sensitive information logging
NPS-2ADA2976F4E0
The OAuth object is logged via console.log(oa) on lines 70 and 107, potentially exposing tokens or secrets in logs.
Insecure default configuration and hardcoded secrets placeholders
NPS-3553AFBBE787
The example uses empty strings for clientID and clientSecret, which if left in place would cause authentication failures. More importantly, the redirect_uri is hardcoded to http://localhost:8080/code without validation, and the state parameter is a static string ('some random string...') rather than a cryptographically random value, weakening CSRF protection. While this is an example file, it demonstrates insecure OAuth practices.
Undefined variable reference
NPS-6EEAF5782446
Inside the callback error handler at line 62, 'res.end()' is called while the actual response object is named 'response'. This undefined reference would throw a runtime error and could indicate copied/modified code or an incomplete implementation.
Unvalidated query parameter usage
NPS-91EA8C378796
The code passes urlObj.query.oauth_token and urlObj.query.oauth_verifier directly to the OAuth library without checking they exist or are strings. Malformed requests could cause unexpected behavior in the OAuth flow.
Insecure default server binding
NPS-E60331953B95
The HTTP server listens on port 3000 without specifying a hostname, causing it to bind to all network interfaces (0.0.0.0) by default. This exposes the OAuth callback endpoint to the local network, potentially allowing other machines to trigger OAuth flows or observe tokens.
Files reviewed
| File | Verdict | What the reviewer saw |
|---|---|---|
| examples/express-gdata/server.js | medium | No malicious patterns detected; however, the code contains security weaknesses including a hardcoded session secret, an open redirect risk, and insecure logging of OAuth objects. |
| examples/github-example.js | medium | The file is an OAuth2 example with insecure practices (static state, hardcoded redirect, token exposure) but contains no malicious patterns such as data exfiltration, backdoors, or code execution. |
| examples/twitter-example.js | medium | This is a legitimately functioning OAuth example for Twitter with no malicious intent, though it demonstrates poor security practices such as hardcoded credential placeholders and binds the server to all interfaces. |
| lib/oauth.js | medium | The OAuth library contains no overtly malicious code, but uses insecure nonce generation and unsafe redirect following that could weaken security or leak credentials. |
| examples/term.ie.oauth-HMAC-SHA1.js | safe | This is a standard OAuth example script that demonstrates OAuth 1.0a flow using the local oauth library; no malicious patterns, data exfiltration, credential harvesting, or other security concerns were identified. |
| index.js | safe | Cleared by Jev triage; no further analysis needed |
| lib/_utils.js | safe | Cleared by Jev triage; no further analysis needed |
| lib/oauth2.js | safe | No malicious patterns detected; the code is a standard OAuth2 client library implementation with no data exfiltration, credential harvesting, obfuscation, or suspicious behavior. |
| lib/sha1.js | safe | Cleared by Jev triage; no further analysis needed |
Frequently asked questions
Is oauth safe to use?
No confirmed malware was found in oauth@0.9.15, but the review flagged 7 medium, 6 low severity findings for risky patterns worth checking before you rely on it.
Does oauth contain malware?
No malware was identified in oauth@0.9.15 when Togoder Security scanned it on Oct 6, 2026. A new version can still introduce malicious code, so scan the exact versions in your lockfile.
How was oauth checked?
Togoder Security downloaded the published npm package and had an AI model read its 9 source files, looking for install scripts, credential access, network exfiltration, obfuscation, backdoors and crypto-wallet theft. The results are cached by file hash and shown here.
How do I scan oauth together with the rest of my dependencies?
Upload your lockfile at https://security.togoder.click/scan or call the API documented at https://security.togoder.click/api-docs. Files that have already been scanned, like the ones in oauth@0.9.15, cost nothing.