alist-partner

Laravel Passport signs every OAuth2 / personal-access token with the RSA private key in storage/oauth-private.key. That key is committed and currently tracked in the repository (verified: git check-ignore returns not-ignored and the file begins with a BEGIN RSA PRIVATE KEY block). Anyone with read access to the repo, a clone, fork, or backup possesses the signing key.

An attacker holding the private key can forge a validly-signed Passport access token for ANY account id, including admin accounts, completely bypassing the Twilio-OTP login. Because all controller authorization keys off Account.registration_type, a forged admin token grants full control of accounts, venues, campaigns, voucher codes and bulk-delete operations. This is a complete authentication bypass for the entire authenticated API surface, independent of every other control in the app.

Confirmed both files tracked and the private-key PEM present at HEAD; this is the single highest-impact finding and subsumes the need for any other auth bypass.

The application .env was committed twice and only later untracked, leaving live credentials permanently in git history. Recoverable secrets: a Twilio Account SID + Auth Token, two MySQL credential sets tied to shared parhaman_* databases, and the Laravel APP_KEY. The username parhaman_alist reveals the cPanel/hosting account prefix and the password !0325Parham! is a guessable human pattern.

Anyone with repo (or clone/fork/backup) access can: (1) take over the Twilio account for toll fraud / OTP interception and drain balance, (2) attempt direct MySQL access to the shared production database exposing all partner, venue, campaign and cross-app PII, and (3) use APP_KEY to forge Laravel encrypted payloads (see AP-03). Because the DB is shared across A-List services, blast radius extends beyond this repo.

Confirmed via git show on both commits; identical APP_KEY in both versions ties this to AP-03.

The only access control on the public POST /api/update/account endpoint is Crypt::decryptString() of an attacker-supplied offer_token, which is keyed by APP_KEY (AES-256-CBC + HMAC). Because APP_KEY is exposed in git history (AP-02), an attacker can encrypt their own {"offer_id":N} payload with the leaked key and produce a valid offer_token, bypassing the secret-token gate. The same known key allows forging/decrypting any Laravel encrypted cookie/session and any Crypt-encrypted DB column.

An unauthenticated attacker can mint valid offer_tokens for arbitrary offer_ids and trigger updateOffersCount, recomputing/overwriting account.food_offers_count for the venue that owns the offer (data-integrity tampering of dashboard metrics; the value is recomputed server-side so it cannot be set to an arbitrary number). More broadly a known APP_KEY undermines all Laravel encrypted payloads until rotated.

Confirmed route is outside auth:api and the decrypt-only gate. Impact tempered because food_offers_count is recomputed from server-side published-offer counts (and the foodOffers relation FK 'restaurant_name' may even be broken), not set to a client value — hence I:L not I:H.

A migration seeds the SAME static plaintext value '982154' as urgent_otp for every admin account. verifyOtp() grants a full Passport access token whenever registration_type==='admin' AND urgent_otp == submitted otp (loose ==), reached on any non-approved Twilio result. The value is committed to git, identical across all admins and environments, never rotated, and the send path actively steers admins to it when Twilio errors. Admin phone/country_code identifiers are also committed in AccountSeeder.

Any attacker who knows (or enumerates) an admin phone+country_code can call public POST /api/verify-otp with otp=982154 and receive a valid admin Passport token — complete administrative takeover with no possession factor. Even without prior knowledge the 6-digit code is brute-forceable in <=10^6 attempts because there is no rate limiting (AP-15).

Confirmed in migration + controller. The == is loose but the column is a string so PHP type-juggling is a secondary issue; the core flaw is a committed static shared secret.

AccountsController::update() loads the target account purely from the {id} path with no ownership or role verification, validates a body that explicitly permits registration_type in {admin,accounts,subadmin}, and calls $account->update($validated). registration_type is in $fillable and is the field every authorization decision keys off. A low-privilege 'accounts' partner holding any valid Passport token can POST /api/account/{own_id} with {country_code,registration_type:'admin'} and become admin. The same missing object-level check also lets them rewrite any other account's id, email, phone or status.

Vertical privilege escalation from a normal partner to full admin in one request (unlocking every admin path and the urgent_otp login), plus horizontal account takeover of arbitrary accounts (email/phone rewrite then PIN reset). Effectively a complete authorization bypass for the partner portal.

Confirmed; raw set listed this twice (injection + access_control dimensions) — merged here. Only country_code and registration_type are 'required' on update, so the body is trivial to satisfy.

VenuesController::store()/update() move uploaded trade_license_file and vat_certificate_file into public_path('assets/uploads/venues/files') using the client-supplied extension with no server-side type enforcement; the only validate() call covers three unrelated text fields. The image-field $validate_array is declared but never executed. uploadVenueFiles() preserves the client filename and writes into the public menu directory. Because the destination is inside the web root, an authenticated partner can upload a .php (or .phtml) file and request it directly to achieve RCE on a PHP-executing host.

Remote code execution / web shell by any authenticated account (including the lowest 'accounts' role, which can reach POST /api/add/venue, POST /api/venue/{id}, POST /api/upload/files) on a server that executes PHP from the uploads path. Full server compromise, data exfiltration, lateral movement. Secondary: stored XSS via SVG/HTML and malware hosting on a trusted domain.

Confirmed dead validation and web-root move with attacker-controlled extension. RCE is conditional on the web server executing PHP from uploads (common on shared LAMP hosts per the public_path pattern), so scored 8.8 rather than 10.

destroy(), bulkDelete() and bulkUpdateStatus() on accounts, and destroy()/bulkDelete() on campaigns, perform destructive operations on arbitrary ids from the request with zero authorization logic — they do not even call Auth::user(). Any authenticated partner can soft-delete or deactivate any account (or all accounts) and soft-delete any campaign by enumerating sequential integer ids.

Tenant-wide denial of service and integrity destruction: a single partner token can set status=inactive on every account (sendOtp rejects inactive accounts, locking out all logins including admins) or soft-delete every account/campaign in the shared platform. Sequential ids make full enumeration trivial.

Confirmed across both controllers; merged the account-bulk and campaign-bulk findings into one BFLA entry.

AccountSeeder hardcodes the OAuth personal-access-client secret and inserts it directly into oauth_clients. This secret is the credential Passport uses to mint personal access tokens (the exact mechanism createToken('otp-login') depends on). There is no Passport::hashClientSecrets() configuration, so it is stored and compared as plaintext, and the seed value is almost certainly the production value.

Disclosure of the personal-access-client secret lets an attacker who can reach the token issuance machinery (or who can write to/read the DB) mint personal access tokens for arbitrary accounts, undermining the integrity of the bearer-token scheme. Combined with the committed admin identifiers it materially aids admin impersonation. (Partly redundant with AP-01, which is the cleaner path, but this is an independent compromised credential.)

Confirmed in seeder; no hashClientSecrets anywhere. Scored just under AP-01 because the raw private key (AP-01) is the more direct forgery primitive.

The seeder creates three live admin accounts with publicly committed phone numbers/emails and an identical PIN of 123456 used for the sensitive-action re-auth gate (POST /api/validate/pin). The PIN is a 4-6 digit value, shared across all three admins, and committed in git. These are the same accounts targeted by the urgent_otp backdoor (AP-04).

Attackers who pull the repo know valid admin login identifiers and the secondary PIN re-auth value, removing the step-up factor protecting sensitive operations and confirming which accounts to target for the OTP bypass. Predictable seeded credentials are directly exploitable in any environment that ran db:seed.

Confirmed; PIN is hashed at rest (good) but the value is committed and shared, defeating the hashing.

List/dashboard queries correctly scope to the caller's venues for the 'accounts' role, proving an ownership model exists, but the per-object endpoints reached by {id} do not apply it. show, voucherCodes, byDateCampaign, dedicatedOfferDetails read any campaign; updateAccountStatus/dedAccountStatus/creatorStatusUpdate write approval state on any campaign/offer-user. Ids are sequential integers (the Hashids campaign_id is only a display field; routes consume the raw integer).

Cross-tenant breach of influencer PII (name, email, Instagram handle, follower data) and theft of voucher/offer codes for any merchant, plus unauthorized approval/rejection of competitors' campaigns and flipping creator decisions — integrity and confidentiality loss across the shared database.

Confirmed; merged the access_control and business_logic copies of this finding.

VenuesController::update fetches a venue by URL id with no authorization and writes an attacker-supplied account_id, contact info and file paths; none of these methods call Auth::user(). show() returns any venue with its uploaded trade-license/VAT documents and offers. deleteVenueFile() deletes any VenueFiles row by id.

Cross-tenant venue takeover: a partner can reassign any merchant venue to themselves (account_id = own id), claiming its campaigns/offer counts; exfiltrate sensitive uploaded business documents served from the public web root; or destroy other merchants' uploaded files. Integrity and confidentiality impact across all venues.

Confirmed; venueFiles are served from public web root, so document exfil is direct.

show() loads an account by URL id with its venues and returns it with no authorization. A partner can enumerate sequential ids and read every account's first_name, last_name, email, phone, country_code, account_type, status, created_by and linked venues. pin/urgent_otp are hidden via $hidden, but the rest leaks.

Mass disclosure of partner/merchant contact PII across the whole tenant via sequential id enumeration; enables targeted phishing and supplies valid ids for the escalation (AP-05) and bulk-delete (AP-07) attacks.

Confirmed; sensitive pin/urgent_otp are $hidden so confidentiality is High not Critical.

store() is reachable by any authenticated user (no role check) and mass-assigns $validated into Account::create(). The validator permits registration_type=admin|subadmin and status=active, both $fillable, so a non-admin caller can create brand-new admin/subadmin accounts. Lower-impact sibling of AP-05 (creates new privileged identities rather than escalating the session) but provides persistence.

An authenticated low-privilege user can create new admin/subadmin accounts (persistence / privilege escalation) and pre-set status=active, bypassing onboarding controls. Requires a unique email and phone, slightly raising the bar.

Confirmed; impact I:H, C:L (creates an account, limited read).

This is the mechanism/secondary view of AP-04: verifyOtp accepts a static plaintext urgent_otp for admins using loose == comparison (type-juggling risk against a JSON numeric otp), and sendOtp fails open by advertising the emergency path whenever Twilio errors. Kept distinct from AP-04 to capture the fail-open/loose-comparison design defects beyond the committed value.

Admin account takeover bypassing the OTP second factor whenever the static code is leaked, guessed, or brute-forced (no rate limiting / lockout), and the fail-open send path makes the bypass discoverable and reachable on demand (e.g. by degrading Twilio reachability).

Confirmed; overlaps AP-04 but captures the loose-== and fail-open design issues separately for remediation tracking.

Neither the OTP send/verify endpoints, the phone-change OTP endpoints, nor the validatePin endpoint carry any throttle/RateLimiter middleware, and Laravel 11's empty withMiddleware() closure means the api group has no throttle:api. OTP verification, urgent_otp guessing, and the 4-digit PIN all allow unlimited attempts; sendOtp can be abused for SMS-pumping/toll fraud and account enumeration (distinct 'Account not found' vs 'pending' responses).

Brute force of the static admin urgent_otp (982154) yields admin tokens; brute force of the 10^4 PIN space clears step-up auth; SMS-pumping drives Twilio cost; enumeration reveals registered/admin phone numbers. The missing throttle is the primary control that would otherwise blunt AP-04/AP-09.

Confirmed empty withMiddleware and zero throttle usage; merged the two raw rate-limit findings (auth_jwt + business_logic).

Both the production and development Slack incoming-webhook URLs are hardcoded as string literals in config/thirdparty.php and committed to git rather than loaded from env. A Slack incoming-webhook URL is itself a bearer credential — anyone holding it can post arbitrary messages into the target channel.

Anyone with repo or git-history read access can spoof campaign-approval and other notifications into A-List's live signup Slack channel (social-engineering / fraud / spam) and flood it. Because the value is in history, rotation requires invalidating the webhook, not just editing the file.

Confirmed; merged the three duplicate scanner entries (secrets_crypto + supply_chain) into one.

The committed .env.example — copied to .env during the documented setup — ships APP_ENV=local and APP_DEBUG=true. If deployed as-is (common for small teams), Laravel renders Ignition/Whoops detailed stack traces, env dumps, DB queries and source snippets on any uncaught exception. A misset APP_ENV also silently routes production Slack approvals to the dev workspace.

Full stack traces, file paths, framework/PHP versions, DB connection details and partial env data exposed to any unauthenticated client on error, enabling targeted exploitation; misset APP_ENV leaks operational notifications to the wrong Slack workspace.

Confirmed defaults; 'likely' because actual prod override is unverified, but the committed .env also had APP_DEBUG=true, raising the odds.

Three workflows call reusable workflows from the external repo laravel/.github by the mutable branch ref @main. pull-requests.yml is triggered by pull_request_target (runs in the BASE repo context with secrets and a privileged GITHUB_TOKEN, even for fork PRs) and grants pull-requests: write; issues.yml grants issues: write; update-changelog.yml grants contents: write. Mutable third-party code + privileged trigger/permissions is the classic Actions supply-chain pattern.

A compromise or malicious change of laravel/.github@main executes attacker-controlled steps with contents/pull-requests/issues write and access to repository secrets, allowing codebase poisoning, PR/issue manipulation, and secret exfiltration. pull_request_target makes the privileged context reachable from fork PRs.

Confirmed exact triggers/permissions/refs in all three workflow files.

Every controller wraps logic in try/catch(\Throwable) and returns $e->getMessage() in the 500 body, independent of APP_DEBUG, including on unauthenticated endpoints (verify-otp, update/account). DB/driver exceptions leak SQL fragments, table/column names, file paths and crypto failure reasons. The unauthenticated /test-db debug endpoint additionally dumps the first 5 venue rows and raw DB errors.

Information disclosure that accelerates further attacks: schema/column discovery (aiding BOLA targeting and the mass-assignment field discovery), internal path disclosure, Twilio/crypto failure-mode oracles, and confirmation of the shared parhaman_* database. /test-db leaks live venue PII to anyone on the internet.

Confirmed across all four controllers and web.php; merged the four duplicate scanner entries (secrets_crypto/injection/auth_jwt/ssrf).

Authentication issues Passport personal access tokens with no lifetime configuration, so they use Passport's long default lifetime. There is no logout route, no revocation on phone-number change or status=inactive, and no blocklist. verifyOtpUpdate issues a new token but leaves prior tokens live after a security-relevant change.

A stolen or leaked bearer token (via the error-disclosure oracle, the auth bypasses here, device theft, or the leaked signing key) stays valid for an extended period, survives logout and phone change, and cannot be invalidated short of manual DB edits — widening the takeover window and hampering incident response.

Confirmed no Passport:: configuration and no logout route; 'likely' as the default lifetime's exact value isn't asserted here.

No action or reusable workflow is pinned to an immutable commit SHA. checkout@v4 and setup-php@v2 float on major-version tags; laravel/.github@main is a moving branch. setup-php downloads and installs the PHP toolchain during the job, so a tampered tag runs attacker code on the runner.

A compromised or maliciously re-tagged action executes attacker code on the CI runner with that job's GITHUB_TOKEN scope and secrets — build-artifact poisoning and code tampering across the pipeline, not just the privileged workflows.

Confirmed; lower than AP-18 because tests.yml has only contents:read and no pull_request_target.

tests.yml runs only on push to master or *.x (plus pull_request and a nightly cron). The repo's only branch is main, so push never fires for normal development, and the suite is just Laravel example stubs. There is effectively no automated security/quality gate validating commits to the shipping branch.

No build-integrity or test gate executes on the branch that is deployed, so regressions, dependency drift, or introduced vulnerabilities are not caught before merge. This is the systemic precondition amplifying every other supply-chain risk (nothing scans lockfiles on push).

Confirmed branch mismatch and stub-only tests.

In sendOtp, if Twilio throws for any reason, admin accounts receive success:true with a prompt to enter the emergency OTP — the application advertises and steers admins to the static urgent_otp backdoor whenever the legitimate MFA channel is unavailable, and discloses Twilio status to unauthenticated callers.

Failure-open behavior that funnels admins to the backdoor and an oracle revealing when MFA is degraded; amplifies AP-04/AP-14 by making the fallback discoverable and reachable on demand (e.g. via SMS-pumping rate limits).

Confirmed; distinct from AP-04 (the value) and AP-14 (the comparison) — this is the fail-open send behavior.

Authorization is ad-hoc inline registration_type checks applied inconsistently. listFullAccounts (POST /api/all/accounts) does no role check and exposes the full partner-account set plus soft-deleted records. listBrandsForPurpose trusts a client-supplied account_id to scope, so a partner can supply another account's id to enumerate its venues. Other endpoints (index, listBrands) do gate by role, proving the model is not uniformly enforced.

Horizontal information disclosure: partners can enumerate other partners' account lists (incl. soft-deleted) and venue associations, supporting reconnaissance for the higher-severity IDOR/escalation/bulk-delete attacks.

Confirmed; the index() method's deleted-filter is commented out but listFullAccounts() exposes it live.

updateOffersCount is intentionally public, gated only by Crypt::decryptString of an offer_token. The payload carries issued_at but the code never checks it, so any captured token is replayable forever; there is no nonce, expiry, per-caller binding or rate limit. The recompute derives food_offers_count from server-side published-offer data (so it cannot be set arbitrarily), but the endpoint is fully replayable and leaks campaign existence/state to unauthenticated callers.

Unauthenticated, indefinitely-replayable state mutation of an account counter and an offer existence/state enumeration oracle. Full forgery if APP_KEY leaks (it has — AP-03). Low direct financial impact because the value is recomputed server-side.

Confirmed; this is the design/replay view that complements AP-03 (the crypto/forgery view). Kept separate because the remediation (replay protection, TTL, nonce) differs from rotating APP_KEY.

Approval handlers check offer_status then later set account_status and notify, non-atomically with no row lock, transaction or idempotency key. Concurrent approve/reject requests for the same offer both pass the guard and both reach the notify block, producing duplicate Slack messages/emails and last-writer-wins races on account_status. The codebase contains zero concurrency control.

Duplicate approval/rejection notifications (Slack + email spam) and inconsistent final state under concurrent requests. Low direct impact here (no monetary double-spend path in this repo), but the absence of any locking becomes a double-spend vector if redemption logic is added to or shared with the influencer service's food_offers_users tables.

Confirmed no transactions/locks anywhere; 'likely' and downgraded to I:L since concrete impact in this repo is duplicate notifications, not double-spend.

All Hashids instances are constructed with no salt, using the library's public default. Hashids is not a cryptographic primitive, and with the default config the encoding is trivially reversible by anyone using the same defaults; sequential integer ids leak adjacency/ordering. The encoded campaign_id is exposed in API responses.

Opaque ids provide no real protection: an attacker can decode them to recover raw sequential database ids, aiding enumeration and the IDOR/BOLA attacks (AP-10/11/12). This is weak obfuscation, not authorization.

Confirmed no salt and no config; low severity — the underlying routes consume the raw integer id anyway, so this only marginally aids enumeration.

There is no automated guardrail (gitleaks/trufflehog pre-commit or CI) to prevent secrets entering the repo, and the .gitignore's vendor entry is byte-corrupted with interleaved null bytes so vendor/ is not actually ignored. This is the root-cause control gap behind the P0/P1 secret findings. NOTE: contrary to one scanner claim, the pattern '*.env' DOES match '.env' (git check-ignore -v .env -> matched by .gitignore:18:*.env), so .env itself is currently ignored — but it was already committed before that mattered.

Secrets will continue to be committable with no detection; the .env / key / webhook / .rnd leaks already demonstrate the gap. Low direct severity but it is the systemic enabler for the critical secret findings.

Confirmed the null-byte corruption via od -c; corrected the scanner's incorrect '.env not matched' sub-claim (it is matched by *.env).

A 1024-byte OpenSSL random seed file (.rnd) was committed. It should never be version-controlled. A stale 1KB seed has low direct value (the PRNG is reseeded from the OS CSPRNG), but its presence indicates openssl was run with $HOME pointed at the repo root during key/cert generation, raising the question whether other generated key material was produced in-tree (cf. AP-01).

Minimal direct cryptographic impact; primarily a hygiene/artifact-leakage indicator that the key-generation process ran inside the working tree.

Confirmed tracked; lowest severity.

No package-lock/yarn.lock/pnpm-lock is committed and all npm deps use caret ranges, so each npm install resolves to whatever latest in-range version exists, with no integrity hashes. This breaks reproducibility and removes lockfile-based integrity defense against a hijacked newer release. Mitigating factor: the JS toolchain is dev-only build tooling unused by the server API, so runtime API exposure is limited to the build/CI host.

Non-deterministic builds; a compromised in-range npm release could be silently pulled into any dev/CI environment running npm install, enabling build-time code execution / credential theft on that host. Absence of a lockfile also blocks automated JS dependency CVE scanning.

Confirmed no lockfile; severity capped because the JS tree is unused at runtime.