alist-android

The EXPO_PUBLIC_INTERCOM_TOKEN committed across all six EAS build profiles base64-decodes to tok:40e437cb_0ad5_4d76_9a04_4efdec5c62d7:1:0, an Intercom Access Token used to authenticate against the Intercom REST API (api.intercom.io). Unlike the public Intercom SDK app keys (android_sdk-/ios_sdk-), an Access Token is a privileged server-grade credential that authorizes programmatic read/write to the workspace's contacts, conversations, companies and admin data. It is hardcoded in plaintext in git-tracked eas.json, read by config/environment.ts, and — because of the EXPO_PUBLIC_ prefix — inlined into the shipped JavaScript bundle.

An attacker who extracts the token (from any shipped binary, the web bundle, or git history) can call the Intercom REST API to enumerate and export the full A-List creator contact list (names, emails, phone numbers — PII), read and write support conversations, impersonate the workspace in messaging, and tamper with CRM data. This is a direct, network-exploitable PII breach affecting all platform users with no device access required. The token is duplicated across 6 profiles, so rotation requires coordinated edits.

Confirmed by base64-decoding the literal and reading the read path in environment.ts:56. Three scanner findings (mobile_storage P0, mobile_api_auth P1 'Identity Verification secret', supply_chain_fe P2 'CI secrets committed') all describe this same tok: value; merged here. The tok: prefix is Intercom's Access Token, the higher-impact interpretation, so kept at P0.

The app has no real refresh-token flow. shared/utils/tokenRefresh.ts re-calls the push device-registration endpoint POST /user/fcm_token (authenticated solely by the existing access token) and treats the JWT returned in that response as a fresh access token, persisting it to SecureStore. This is wired into the default request path (retryOn401:true). Any holder of one valid access token can transparently and indefinitely obtain new JWTs by registering an arbitrary FCM device token — no re-authentication, no proof-of-possession, no rotation. Combined with shouldRefreshToken() always false and exp never decoded, practical token lifetime is unbounded.

A stolen or intercepted access token grants effectively permanent account access: the attacker keeps it alive forever by re-registering a random device token. Token rotation/expiry — the primary mitigation for token theft — is neutralized, and the client exposes no way to invalidate a leaked token short of a backend action it never triggers.

Confirmed end-to-end: the FCM endpoint returns data.token, refreshAuthToken persists it, and request.ts auto-invokes it on 401. CLAUDE.md itself flags this as 'unusual and worth confirming with backend'.

The login OTP verify request to POST /login/verify-otpv2 carries three independently attacker-influenceable values: email, otp, and a distinct user_id (replayed from the requestOtp response). Because identity is conveyed as a separate user_id parameter rather than being derived strictly server-side from the email+OTP pair the server issued, the flow is vulnerable to OTP/identity-binding confusion: if the backend keys the OTP lookup or issued session on the client-supplied user_id (or fails to enforce that email+otp+user_id all reference the same record), an attacker can request an OTP for their own account and substitute a victim user_id/email to have a valid token minted for the victim. Numeric IDs are sequential and client-exposed, making enumeration trivial.

Potential full account takeover of arbitrary users by manipulating user_id (and/or email) in the verify-otp request, bypassing the OTP second factor. Even absent full takeover it weakens OTP binding and enables targeted abuse.

Client-side contract confirmed (separate user_id param accepted and forwarded; sequential id exposed). Marked 'likely' because full exploitability depends on unverified backend binding logic — but the client design is a textbook BOLA smell.

Every network call — the centralized request.ts wrapper and all raw fetch() call sites — relies solely on the device OS trust store to validate the server certificate. There is no certificate pinning, public-key pinning, or Certificate Transparency enforcement anywhere in the codebase, and because this is a pure managed Expo build with no native config, even the baseline of excluding user-installed CAs is not asserted.

An on-path attacker who can get a CA trusted on the victim's device (rogue Wi-Fi captive portal, corporate MDM, malware-installed user CA, or a compromised public CA) can decrypt and modify all traffic: steal the Bearer JWT (account takeover, amplified by AA-02), capture the email+OTP during login, alter offer-redemption/venue-verification flows, and harvest PII.

Confirmed absence by grep and dependency/plugin review. Severity P1 because it is the precondition that elevates AA-02, AA-03, AA-05, AA-07 and the WebView injection (AA-06).

The repository ships no dependency lockfile. A package-lock.json existed at the first commit but was deleted on 2026-05-14 and added to .gitignore. With ~60 of ~81 declared dependencies using caret/tilde ranges, every npm install (the documented and only install path, including on EAS Build workers) re-resolves the full graph from the registry at build time with no recorded resolved versions and no integrity hashes. This is the canonical precondition for a supply-chain attack and makes builds non-reproducible.

An attacker who compromises any package in the unpinned transitive tree — or publishes a malicious patch/minor within an allowed range — gets code executed on developer machines and EAS Build infrastructure, bundled into the shipped app, invisibly until a build behaves maliciously. Builds are irreproducible, undermining incident forensics.

Confirmed lockfile deletion and .gitignore exclusion via git history and file listing. The historical stale-lockfile detail (SDK 53/RN 0.79) is folded into this finding as corroborating evidence.

The only in-app WebView renders a URL supplied by the backend legal endpoints (terms/privacy) using react-native-webview defaults: JavaScript enabled, no originWhitelist, no onShouldStartLoadWithRequest scheme/host gating, setSupportMultipleWindows left at default true. The URL originates from unauthenticated GET /user-terms and /privacy-policy (and a SecureStore cache) on the dev-pointed production backend. Anyone who can influence that response — compromised dev API, MITM on the unpinned channel (AA-04), or an open-redirect on the served page — controls a fully JS-enabled WebView inside the authenticated app chrome with no navigation gating.

An attacker who influences the legal-URL response gets arbitrary JavaScript execution in an in-app WebView with no origin restrictions, enabling credential/OTP phishing pages indistinguishable from the app, redirect chains to attacker origins, and cleartext content loads. No JS bridge limits direct native RCE, but the content-injection primitive inside trusted chrome is real.

Two scanner findings (mobile_platform P1 insecure defaults; mobile_transport P2 server-controlled URL no validation) describe the same WebView; merged. Confirmed by reading InAppBrowser.tsx and both legal.ts files (unauthenticated GET). Kept P1 per the higher scanner rating.

The login second factor is a 4-digit numeric OTP (keyspace 10,000). The client imposes no attempt limiting, no exponential backoff, no lockout after repeated failures, and no resend cooldown, and the verify endpoint is a plain POST with no nonce/captcha, so it is directly scriptable. Rate-limiting must ultimately be server-side, but the complete absence of any client control combined with the tiny keyspace means that if backend per-account attempt caps or OTP TTLs are weak, the code is brute-forceable in seconds.

If server-side throttling is weak or absent, an attacker can brute-force the 4-digit OTP for any email and authenticate as that user, fully bypassing the OTP factor.

Client-side absence of all anti-automation confirmed; 4-digit length confirmed in loginHelpers constants. 'likely' because real-world brute-forceability hinges on unverified server throttling, but the design is materially weaker than the 6-digit standard.

The project has no CI pipeline and no dependency-scanning automation (no Snyk, Dependabot, Renovate, npm audit, or SBOM step). Combined with the missing lockfile (AA-05), there is no automated point at which a vulnerable, outdated, or malicious dependency is detected before it reaches a build artifact, and new CVEs against the ~80 declared packages are never surfaced. Releases are cut by running EAS Build manually from developer machines.

Vulnerable or compromised dependencies enter shipped builds undetected; there is no quality gate to block a known-CVE or malicious version. The manual, machine-local release process widens the trust boundary to every contributor workstation, and mean-time-to-detect for a supply-chain compromise is effectively unbounded.

Confirmed absence of all CI/SCA config. Distinct from AA-05 (integrity anchoring) — this is the missing detection/gate layer; both are systemic.

logout() and the 401 force-logout path only delete the locally-stored token and clear local state; they never ask the backend to invalidate the JWT. The only server call during logout is unregisterFCMToken (DELETE /user/fcm_token), which removes the push device, not the auth session, and its failure is swallowed. The JWT therefore remains valid server-side after logout, so any copy exfiltrated earlier keeps authenticating until natural expiry — and per AA-02 expiry can be circumvented.

Stolen or cached tokens stay usable after the user logs out, including on shared/lost devices. Users cannot truly terminate a compromised session from the app.

Confirmed by reading authStore.logout, clearAllAuthData, session.ts, and grepping for a logout endpoint (none). Compounds AA-02.

The OTP returned by the backend is rendered into a user-visible Toast. The 'dev only' guard is Environment.api.baseUrl.includes('dev-'), but every EAS profile including production points at dev-api.alist.ae, so the guard is true in production and the OTP is displayed to whoever operates the app. More fundamentally, the backend returning the OTP in the API response at all (data.data?.otp) means the second factor is recoverable by anyone who can read the HTTP response, collapsing the OTP's out-of-band value.

The OTP factor provides little protection if the code is returned in the response and surfaced in the UI; an attacker observing traffic (AA-04) or shoulder-surfing the toast obtains the code directly, and the mis-scoped dev gate leaks OTPs to all production users.

Confirmed all three toast sites and the dev-gate substring logic, plus that all eas.json profiles use dev-api (so the gate fires in prod). Merges the three OTP-leak scanner findings. Kept P2.

Several API modules log full response/request bodies, PII, and OAuth artifacts to console with no __DEV__ guard, so they run in production. On Android, console.* is forwarded to logcat, readable via ADB during support, by some OEM/MDM logging, and by other apps with READ_LOGS on legacy devices. fetchUserProfile/fetchSocialMediaProfile dump the full profile object; connectYoutube logs the OAuth authorization code and state; auth.ts logs login endpoint URLs and truncated server error bodies.

PII and OAuth authorization codes for creators are written to device logs in production. An attacker with local log access (malicious app on legacy Android, physical/ADB access, or log aggregation) can harvest PII and potentially replay an OAuth authorization code before it is exchanged.

Confirmed all cited lines. Merges the mobile_storage P2 PII-logging and mobile_transport P3 auth-URL-logging findings (same root cause).

buildUrl() will issue requests to any caller-supplied absolute URL including plaintext http://, and withAuthHeaders attaches the user's Bearer token regardless of scheme or host. There is no https-only enforcement and no host allowlist, so a misconfiguration, a server-returned URL fed into get()/post(), or a downgrade can transmit the token in cleartext or to an unintended host. The app declares no Android cleartext restriction or iOS ATS config, leaving only the platform default, and IMAGE_BASE_URL is derived by brittle string replacement that inherits any misconfiguration.

Risk of access-token disclosure over cleartext on hostile Wi-Fi, or token leakage to an attacker-controlled host if any URL fed to the request helper is influenced by remote data. Tokens transit in plaintext, enabling session hijacking.

Confirmed buildUrl/withAuthHeaders code and absence of cleartext config. Merges the mobile_api_auth P2 and mobile_transport P2 cleartext findings (same buildUrl root cause).

The app displays security-relevant data on screen — login OTP codes, Instagram/TikTok ownership-verification codes, and redeemable voucher codes — with no screen-capture protection (no Android FLAG_SECURE, no expo-screen-capture, no iOS background blur). These values are captured in OS screenshots, the Android Recents/app-switcher thumbnail, and any screen recording including malware with MediaProjection/accessibility capabilities.

Sensitive auth/verification material leaks via automatic Recents thumbnails, cloud-synced screenshots, or screen-recording malware, enabling account-verification spoofing or voucher theft. Bounded to local/physical or on-device-malware adversaries.

Confirmed absence by grep and dependency review; sensitive-render sites confirmed.

Multiple third-party identifiers are committed: Intercom mobile SDK keys, the Firebase/Google API key in a tracked google-services.json, Google OAuth client IDs, and the Android signing certificate SHA-1. These categories are by design embeddable in mobile clients (SDK keys, OAuth client IDs, and Firebase API keys are documented non-secret, access being controlled server-side), so direct impact is low — but their safety depends entirely on server-side hardening (Firebase Security Rules and GCP API/application restrictions), committing them centralizes exposure and complicates rotation, and they must be distinguished from the genuinely-privileged Intercom Access Token in AA-01.

Low direct impact in isolation. An unrestricted AIzaSy... key can be abused for billed Google API calls or service enumeration if it lacks application + API restrictions; Intercom SDK keys allow initiating anonymous conversations. Repo read access (contractor, leaked clone, mirror) yields the full integration key set in one place, and the six-profile duplication makes rotation error-prone.

Confirmed all literals and that google-services.json is tracked (committed e84bb6d, not gitignored). Distinct from AA-01 because these are the non-privileged class; merges the mobile_storage P2 SDK-keys finding and the supply_chain P2 committed-config finding (excluding the tok: token, which is AA-01).

react-native-render-html@^6.3.4 is an abandoned/archived library used pervasively to render HTML from the API (offer/voucher descriptions, deliverable rules, voucher redemption/booking text). It renders to native RN components (so <script> does not execute — not classic web XSS/RCE), but components configure <a> tagsStyles without restricting link href schemes or sanitizing, so backend-authored (and where any field is merchant/user-influenced, attacker-influenced) HTML can present styled hyperlinks to arbitrary URIs (alistapplication://, javascript:, phishing https) and arbitrary inline markup. Because the package is unmaintained, any CVE in it or its bundled parser tree (ReDoS/parser-confusion classes historically seen in nth-check/css-select/htmlparser2) will never be patched in place, and the floating ^6.3.4 range cannot upgrade to a fixed major because none will be published.

No security patches will ever arrive for a component that processes remote, attacker-influenceable HTML on every offer/voucher view, across the core browse/redeem flows (high blast radius). A future or existing parser CVE (ReDoS/crash/link abuse) is permanently unpatchable, and unsanitized anchors enable in-app link phishing. The dev-pointed production API (AA-06 context) weakens the 'trusted backend' assumption.

Confirmed 8 call sites and server-data binding by grep + reading OfferContent.tsx. Merges the supply_chain P2 unmaintained-dep finding and the mobile_platform P3 unsanitized-HTML finding (same component/library); kept P2.

Every function in the SecureStore-backed storage layer wraps its body in a try/catch that silently discards the error. SecureStore itself is correctly used for encrypted-at-rest storage, but silent swallowing means a failed clearToken/clearAllAuthData during logout (Keychain/Keystore error) leaves the auth token and PII resident while the UI shows a successful logout. It also hides integrity/decryption failures that could indicate tampering, with no telemetry to surface them.

On a shared or lost device, an incomplete logout can leave a valid bearer token and profile PII in SecureStore with the user believing they signed out, enabling session continuation by the next device holder. Integrity-affecting, low likelihood, compounded by the absence of crash/error reporting and by AA-09 (no server revocation).

Confirmed the silent-catch pattern throughout storage.ts and the Promise.all silent catch in clearAllAuthData.

Multiple auth/signup endpoints return account-existence and account-state signals for arbitrary inputs: requestOtp returns the numeric user_id (confirming registration), signup Step 1 returns a deleted_account message revealing a prior deleted account, and dedicated validate/email and validate/phone endpoints return existence verdicts. The numeric IDs are sequential and client-exposed, compounding enumeration.

Privacy disclosure and reconnaissance: an attacker can enumerate registered users, identify deleted accounts, and harvest valid targets for phishing, credential-stuffing, and OTP brute-force (AA-07), feeding the other auth weaknesses.

Client-side evidence (id returned, deleted_account message, validate endpoints) confirmed. 'likely' as exploitability depends on the backend's response differentiation, which is strongly implied by the client handling.

On the web target the YouTube OAuth authorization-code flow is built without PKCE, and the state parameter is base64(JSON{creator_id}) — guessable and providing no CSRF protection. The popup result is received via window.addEventListener('message', handleMessage) which reads event.data.code without validating event.origin, so any window/iframe can post a forged message containing an attacker-chosen authorization code, which the app forwards to connectYoutube.

On web, authorization-code injection / OAuth CSRF can cause a victim to link an attacker-controlled YouTube channel (or vice versa). Limited blast radius (channel-connect, not primary auth), hence P3.

Confirmed no PKCE, base64(creator_id) state, and absent origin check by reading YouTubeConnectButton.tsx. Merges the duplicate mobile_api_auth P3 (PKCE/origin) and mobile_transport P3 (state nonce) findings.

The app copies Instagram/TikTok verification PINs and redeemable voucher codes to the global system clipboard via expo-clipboard. On Android (pre-12) and iOS, clipboard contents are readable by any installed app, and iOS syncs the clipboard across devices via Universal Clipboard. Values are not cleared after use and no sensitivity flag is set.

A malicious or background app on the same device can read social-verification PINs (enabling verification hijack) or single-use voucher codes (redemption fraud). Requires a co-resident hostile app; low value per item.

Confirmed all six call sites by grep and reading Step3Verification.tsx.

generateTestFCMToken() builds a 152-char device token from Math.random(), a non-cryptographic PRNG. Although labelled 'test', it is not dead code — tokenRefresh.ts (AA-02) and the login flow (formHandler.ts:421) call it to generate the device_token persisted via saveDeviceToken and registered against /user/fcm_token, which is the same endpoint used to re-mint the JWT.

The device token is low-entropy and predictable. As-is it gates push registration and the FCM-based token re-mint; predictable device identifiers could aid spoofing of device registration. Direct authentication impact is limited because the JWT (not the device token) authorizes the call, hence P3.

Confirmed implementation and that it is reachable from production paths (tokenRefresh.ts and formHandler.ts call it), correcting the scanner's 'dead/test-only' characterization; security impact remains low (P3) because the JWT, not this value, is the credential.

When a push notification is tapped, useNotifications.ts interpolates the server-supplied data.offerId directly into an Expo Router path string without validating it is a numeric id. A crafted push payload could embed path segments or extra query parameters (an offerId containing / or ?/&) to redirect navigation to an unintended internal route or inject route params. All reachable targets are internal Expo Router screens (no external URL, no WebView, no native intent), bounding impact to in-app navigation/parameter confusion.

Low: an actor controlling push payloads can steer a tapped notification to an unintended in-app screen or smuggle route params (UI redress/confusion), with no direct data or privilege escalation since downstream screens still enforce server-side authorization.

Confirmed the unvalidated interpolation in useNotifications.ts and the safer sibling in notificationNavigation.ts. 'likely' because exploitability depends on Expo Router's path parsing tolerance for injected segments.