a-list-ios

The Apple Push Notification service token-signing private key (.p8) is committed in cleartext at the repository root and is git-tracked (not gitignored), present since 2022. A .p8 APNS auth key is a team-wide token-signing key: combined with the Key Id (V63PAFH55F) and Team Id (ASR5MYB7XL) — both helpfully published in the adjacent README — anyone holding it can sign APNS JWT provider tokens (ES256) for every app under the team. It is a server-side credential that has no business living in a client app repo.

Any party with read access to the Bitbucket repo, any clone/branch, or the prior GitLab mirror can forge APNS provider tokens and push arbitrary notifications to ALL A-List users and to any other app under Team ASR5MYB7XL. Enables mass phishing/smishing ('Tap to verify your account' deep-linking into alist://), notification spoofing, and reputational damage. The key never expires; it must be treated as compromised.

Confirmed on disk and in git. CVSS raised to S:C (team-wide blast radius beyond this app); C set to L because the key's primary power is forging/sending (Integrity), not reading user content. Merged the duplicate mobile_storage and supply_chain raw findings. CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:H/A:N.

Two Bitbucket app passwords are hardcoded in the repository — in README and again as comments at the top of AppDelegate.swift (which ships in source archives). Bitbucket app passwords are user-scoped credentials granting API/git access to every repository the owning account can reach across the ParhamandCo (and historically Qubicle) workspace. The credential protecting the source tree is stored inside the source tree.

Anyone with repo read access (or a historical clone/mirror, or unpacked dSYM/source archive) can authenticate to Bitbucket as the credential owner: source theft, malicious commits poisoning the build pipeline of the iOS app and ~12 other A-List repos, and lateral movement across the workspace. Scope=Changed: access extends to systems beyond this app.

Confirmed in both files. Merged the duplicate mobile_storage and supply_chain raw findings. CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N.

The backend returns the one-time login/signup passcode inside the response JSON, and APIManager.validateResponse unconditionally harvests it into the Common.shared.otp singleton on EVERY response (regardless of build flag). The OTP screens auto-populate it when CAN_AUTO_FILL_OTP is true (Dev/pre-prod) and under #if DEBUG. An OTP delivered in the same channel as the request is not a second factor — anyone who can observe the login response obtains the code directly. Combined with ATS-disabled + no pinning (ALI-04), the response is trivially observable on a hostile network. Verification requires only an enumerable user_id plus the otp.

Authentication bypass / account takeover. A network-position attacker who triggers or observes a victim's login response reads the OTP off the wire and completes login as the victim against api.alist.ae. Affects all creator accounts. The OTP factor provides zero added security because it round-trips in the response body. The cached OTP also leaks via the response-logging path.

Confirmed in all cited files. Merged the mobile_storage P2 and mobile_api_auth P0 raw findings. AC:H reflects the realistic prerequisite of observing the response (network position); the in-channel echo itself is the core defect. Kept P0 due to full ATO with no inbox access. CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N.

ATS is globally disabled with no compensating exception scoping, and the single networking choke-point uses Alamofire's default Session with no ServerTrustManager / pinning and no URLSession challenge handler. Together these remove every OS-level transport guarantee: iOS will permit plain-HTTP (e.g. an attacker-injected redirect to http://), TLS downgrade to 1.0/1.1 or non-FS ciphers, and acceptance of any certificate chained to a trusted root — including an attacker CA installed on a target device. This matches the standard Burp mobile-interception workflow succeeding with no pinning bypass needed.

On a hostile network (rogue Wi-Fi, malicious proxy, ARP/DNS spoof, attacker CA on a managed/jailbroken device) an attacker transparently MITMs all API traffic with no client-side error, capturing the Bearer session token (full account takeover), creator PII and offer/redemption data, and tampering with responses. This is the enabling primitive for the OTP-in-response ATO (ALI-03) and the WebView open-redirect (ALI-08).

Confirmed: Info.plist, APIManager Session.default, and zero pinning code. Merged three overlapping raw findings (mobile_transport ATS P1, mobile_transport pinning P1, mobile_api_auth ATS+pinning P1) into one combined transport finding. AV:A/AC:H reflects adjacent-network position requirement. CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N.

On login the full UserModel — including the API bearer token, PIN/confirmPin, email, phone, DOB, nationality and social handles — is encoded via PropertyListEncoder into UserDefaults under key 'User'. The line that would null the token before persistence is disabled. UserDefaults is an unencrypted plist in the app sandbox, captured in unencrypted iTunes/iCloud backups. The request layer reads the token from this UserDefaults copy, not the Keychain. The parallel Keychain entry sets no kSecAttrAccessible, so it too is backup/migration-eligible and keyed by the user's mutable email.

An attacker with local access (jailbreak, lost/unlocked device, forensic extraction of an unencrypted iTunes backup) reads the live bearer token from the plaintext plist and fully impersonates the user, plus a PII trove (PIN, email, phone, DOB) at rest. Because there is no server-side revocation (ALI-07), a recovered token is replayable indefinitely.

Confirmed across Session.swift, UserModel.swift, APIConstants.swift, Keychain.swift. Merged the UserDefaults P1, the Keychain-accessibility P2, and the mobile_api_auth dual-storage P2 raw findings into one credential-storage finding (the Keychain weakness is the same secret's secondary store). CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N.

Authentication uses an opaque server token stored in Session.userDetail.token. The app never parses an expiry, there is no refresh mechanism, and there is no logout or revoke endpoint. Logout — and even account deletion — clear only the local UserDefaults/Keychain copies, so a token captured via MITM (ALI-04), device backup (ALI-06), or logs (ALI-05) remains valid on the server indefinitely. The user cannot invalidate a stolen token.

Any leaked/stolen token is replayable for an unbounded lifetime. Logout gives a false sense of security — the token the user believes invalidated is still accepted by the backend. A single interception becomes long-lived persistent access. PR:L reflects that an attacker needs a (any) valid captured token to exploit.

Confirmed: no logout/refresh endpoint, local-only clear(). Largely a backend/design issue surfaced by the client; CVSS C:H/I:L reflects read-heavy account access with limited integrity impact on its own. CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N.

Instead of the canonical CocoaPods-trunk Siren pod, the app pulls Siren from a personal GitHub fork by git URL. CocoaPods git dependencies lack trunk's published-spec checksum verification; integrity rests solely on the commit hash in Podfile.lock, and the fork is controlled by an individual developer account on infra with no stated branch protection. If the account is compromised or the commit/branch is force-pushed, malicious Swift can be injected on the next pod install/update. Siren executes at every launch and controls the forced-update modal, giving injected code a guaranteed launch-time, all-users execution path.

Compromise of the personal fork (or a malicious maintainer commit) ships arbitrary code into the next signed build that runs at launch for every user and controls the forced-update UX — a software-supply-chain backdoor. The forced-update flow also enables fake 'Update Now' social engineering redirecting users to attacker destinations.

Confirmed Podfile/Podfile.lock fork+commit pin and the launch-time force-update config. Confidence 'likely' (not confirmed) because exploitation requires future fork compromise/force-push; the insecure posture itself is confirmed. CVSS S:C/C-I-A:H reflects worst-case arbitrary-code-at-launch if realized; AC:H for the precondition. CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H.

Every outbound request logs its full HTTPHeaders via debugPrint at APIManager.swift:40, and those headers include Authorization: Bearer <token>. Unlike print (which the app shadows to a no-op in Common.swift), debugPrint is never overridden, so it emits to the unified logging system (os_log/syslog) in production. On-device logs are readable via Console.app while plugged in, sysdiagnose bundles, MDM log collection, and support/telemetry pipelines.

The live session Bearer token plus full request URLs/parameters are written to the device log stream in production builds. Anyone who can pull a sysdiagnose, attach Console, or read captured logs recovers a token that fully impersonates the user against api.alist.ae (and, given no server revocation per ALI-07, indefinitely).

Confirmed: the print override is a no-op AND its body is commented out; debugPrint is not overridden. AC:H reflects log-capture access requirement. CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N.

The Terms and Privacy WebViews load a server-controlled URL (WebApiModel.data) with no scheme/host validation, then delegate any in-page navigation whose URL differs from the loaded document to UIApplication.shared.open() with no scheme allow-list. Because ATS is off and the API channel is unpinned (ALI-04), an on-path attacker can serve a MITM'd/plaintext page and inject markup/JS that triggers navigation to arbitrary schemes (tel:, sms:, mailto:, itms-apps://, shortcuts://, or any installed-app custom scheme), which the handler forwards straight into the iOS URL dispatcher — escaping the WebView into other apps. JS is enabled by default, so injected script can also run in the in-app chrome.

A MITM attacker can cause the app to silently launch arbitrary URL schemes (place calls, pre-fill SMS, open App Store pages, deep-link into other apps performing sensitive actions) and run arbitrary JavaScript inside the trusted in-app WebView, enabling phishing/content-spoofing within the app's chrome. Scope=Changed: control crosses from the WebView into other apps / the OS URL dispatcher. Realistic only once the channel is MITM'd (depends on ALI-04).

Confirmed in both VCs. Merged the two raw transport WebView findings (cleartext-load P3 and decidePolicyFor open-redirect P1) — same code paths. Net P2: real, but gated behind achieving MITM (ALI-04) and limited to static legal screens; CVSS reflects S:C with low C/I. CVSS:3.1/AV:A/AC:H/PR:N/UI:R/S:C/C:L/I:L/A:N.

There is no CI/CD pipeline and no automated security gating. Builds and App Store/TestFlight uploads are manual in Xcode. No SCA (Snyk/Dependency-Check), no SBOM generation, no Dependabot, no secret scanning, and no enforced provenance/integrity check on the git/vendored dependencies (Siren fork ALI-09, QRCode copy ALI-13). This systemic gap is the root cause that let the P0 secret leaks persist for years.

New CVEs in the bundled pods/transitive components and in the vendored/forked dependencies go undetected and unpatched; secrets can be committed without alerting; a tampered dependency can reach a signed build with no automated gate. Test coverage is also effectively zero (both test targets are template stubs).

Confirmed absence of all CI/security tooling. Merged the no-CI/SCA finding with the prior audit's 'zero test coverage / no CI' quality note. P2 systemic root-cause. CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N.

Unlike every other authenticated endpoint (which derives Authorization from the live session via API.authToken), the resetPin request type builds its Authorization header from a token value carried inside the request parameter dictionary. The credential authorizing a security-sensitive PIN-reset is taken from caller-controlled input rather than the authenticated session. In normal flow the client populates this from a short-lived reset token (AccountViewModel.token), but the pattern means the operation's security hinges entirely on the server strictly binding that arbitrary token to the target account.

Inconsistent, parameter-driven authentication for PIN reset enables token-confusion / authorization-bypass if the backend does not strictly bind the presented token to the authenticated subject, and broadens the blast radius of any leaked/lower-privilege token. Server-side validation cannot be confirmed from the client, so this is a latent design weakness rather than a proven bypass.

Confirmed the client builds the header from param["token"]. Downgraded from the scanner's P2 to P3 and confidence to 'likely': there is no evidence the client value is attacker-controlled beyond any normal token, and exploitability depends on unverified server behavior. PR:L/AC:H reflect needing a valid token and server mis-binding. CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N.

Submitting just an email to login/with-otp returns the account's existence and lifecycle status (approved/pending/rejected plus restricted_days) before any OTP challenge, and the client branches into different flows accordingly. The API discloses whether an email is a registered creator and its moderation state to an unauthenticated caller.

Unauthenticated attackers can enumerate valid creator emails and learn approval/rejection status, aiding targeted phishing, credential-stuffing list-building, and competitive intelligence on the invite-only creator base.

Confirmed in LoginViewController and UserModel. Primarily a backend response-design issue observable via the client; rated P3. CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N.

Social-account verification PINs and offer voucher/redemption codes are written to UIPasteboard.general — the system-wide pasteboard readable by any other app while data persists, synced across devices via Universal Clipboard, and on older iOS persistent across reboots. These values are security-relevant: the social PIN is proof-of-ownership for a creator's Instagram/TikTok account, and the voucher code authorizes a venue redemption. No expiration or local-only restriction is set.

A malicious or curious app on the device (or another of the user's devices via Universal Clipboard) can silently read social-verification PINs and voucher codes, enabling impersonation of the verification step or unauthorized voucher redemption. Confidentiality-only; requires the user to copy and an attacker app to be present.

Confirmed all four call sites. P3: confidentiality-only, requires a malicious app present and a user copy action. CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N.

The dagronf/QRCode library is bundled by copying its entire source tree into A-List/QRCode/ rather than declared as a versioned dependency. With no version pin or lockfile entry there is no record of the upstream release/commit, no integrity/provenance check, and no path for tooling to surface upstream security fixes. QRCode parses untrusted input (scanned QR codes from venue/offer materials, plus embedded link/contact/SMS decoders), so a parser bug in a frozen, unpatchable copy is a realistic exposure.

The app may run an outdated, unpatchable QR-parsing library that processes attacker-influenceable QR payloads, with no mechanism to detect or remediate upstream vulnerabilities and no provenance verification (a tampered copy would go undetected).

Confirmed vendored tree and absence from Podfile.lock. P3: today's confirmed-exploitable risk is low; concern is the unpatchable/unprovenanced trajectory. CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:L.

Every significant dependency is pinned to a 2022-2023 release with no update mechanism (see ALI-14). No single pinned version maps to a confirmed critical, clearly-reachable published CVE in this app's usage at review time, so this is rated low/informational rather than a concrete exploit. The baseline is ~3 years behind across networking (Alamofire), analytics/push (Firebase/GoogleUtilities/nanopb), auth (GoogleSignIn/AppAuth), and two parallel image-decoding stacks that parse untrusted remote bytes.

Increasing latent exposure to newly disclosed vulnerabilities in stale components (notably image decoders and the networking layer handling untrusted remote data), with no detection or patch path. Today's confirmed-exploitable risk is low; the trajectory and duplicate image-parser surface are the concern.

Confirmed pins against vendored Pods/. P3: no concrete reachable critical CVE confirmed at review; rated on trajectory + duplicate image stacks. No specific CVE assigned to avoid a false positive. CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:N.

The Intercom mobile SDK API key (ios_sdk- prefix) and app id are hardcoded in source. Intercom iOS SDK keys are designed to ship in clients and are extractable from any IPA, so this is low-severity, but committing them in source and git history exposes them to repo readers and, if Intercom Identity Verification (HMAC) is not enforced, can permit identity spoofing of conversations / messaging-surface abuse.

If secure identity verification is not enabled in the Intercom workspace, the disclosed client key allows driving the Intercom API surface (e.g. create/spoof user conversations) and contributes to backend fingerprinting. Low because client SDK keys are extractable from any IPA by design.

Confirmed at SceneDelegate.swift:22. Client SDK key; P3 by design. CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N.

The Firebase iOS config plist (with the Google API key, project id, sender id, app id) is committed and also ships inside the IPA — expected for Firebase iOS clients; the API key is not itself a high-value secret. The real risk is if the GCP API key lacks application (iOS bundle-id) and API restrictions, allowing reuse against billed Google APIs. Committing it (vs build-time injection) additionally leaves identifiers in source history/mirrors.

If the key lacks bundle-id/API restrictions, an attacker who extracts it (repo or IPA) could call enabled Google APIs against project alist-application, risking quota/billing abuse and enumeration. Real exploitability depends on key restrictions in the Google Cloud console (not verifiable via static review).

Confirmed tracked + key contents. P3 informational; impact contingent on unverifiable cloud-side key restrictions. CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N.

Developer test identities are embedded in source. The LoginViewController email prefill is correctly wrapped in #if DEBUG and stripped from Release. However the DummyData enum (test email rahulk2133@gmail.com and PIN 1234) in Constants.swift is NOT compile-gated and ships in every build, disclosing a developer email and a guessable default PIN that may map to a real test account.

Low: discloses a developer/test email and a weak default PIN that an attacker recovering strings from the IPA can try against the auth/PIN flow. Mostly information-disclosure/hygiene and an indicator of dev artifacts reaching production.

Confirmed: DummyData ungated, LoginVC prefill DEBUG-gated. P3 hygiene. CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N.