a-list-demo

The admin route group applies only a URL prefix and namespace; the 'admin' middleware group it runs under contains no authentication middleware. The dedicated AdminAuthValidate middleware exists but is wired only to a commented-out route. GET admin endpoints whose controllers also lack a constructor auth check are reachable with no login at all.

Unauthenticated read/export of all influencer PII (signups: name, email, mobile, Instagram, nationality, DOB) via GET /admin/usersList and /admin/exportSignups, plus block/suspend, offer/venue mutation, and audit-PDF deletion. Confidentiality, integrity, and availability all impacted with zero credentials.

Confirmed by reading routes/admin.php, RouteServiceProvider, and Kernel.php. Many admin controllers DO call middleware('auth') in their constructor (ALD-02), so those endpoints still require some authenticated users-table session; GET routes on controllers without that constructor (and the route group's missing gate) are the fully-open ones. Severity remains P0 because ALD-02/ALD-03 collapse 'authenticated' into 'admin'.

Every admin controller calls $this->middleware('auth') with no guard, resolving the default 'web' guard backed by the users table. The User model/users table has no role or is_admin attribute, so authentication equals authorization: any users-table account is implicitly a full administrator. No per-action privilege check exists anywhere.

Vertical privilege escalation — any single users-table account (including a self-registered one, see ALD-03) yields complete administrative control. Any credential compromise of any account is full platform compromise.

Confirmed: AdminController.php:25-28, config/auth.php has only 'web' and 'chat_agent' guards, User model has no role field.

web.php disables registration, but admin.php calls bare Auth::routes() inside the /admin prefix, re-registering POST /admin/register backed by the stock RegisterController. It creates a users-table row and redirects to /admin/dashboard. Because any users-table account is treated as admin (ALD-02), an anonymous attacker can register themselves into full admin in one request.

Anonymous attacker to administrator in a single POST. Defeats any future login gate that merely checks for an authenticated users-table account.

Confirmed: routes/admin.php:14 bare Auth::routes() vs routes/web.php:16 register=>false; RegisterController redirects to /admin/dashboard.

filterPreviews builds a large raw SQL string for DB::select by concatenating request-controlled venues, instagram_followers, search value, and pagination start/length with zero parameterization. str_replace('Pending',...) does not neutralize SQL metacharacters. The IN lists, WHERE/LIKE clauses, and LIMIT are all injectable.

Full database read (and write/file ops depending on grants) including signups PII and credentials. Error-based extraction is trivial with APP_DEBUG=true. A low-privilege (or self-registered) authenticated session suffices.

Confirmed by reading UsersPreviewsController.php:185-282. Tainted values traced from request to query string.

auditPdfDownload passes request pdf_content verbatim to CreatePdfJob, which renders it through DomPDF with isRemoteEnabled=true; the Blade template prints it with {!! !!}. Attacker HTML (img/link/@import to http://169.254.169.254/, http://127.0.0.1:port, or file:///etc/passwd) forces server-side fetches, and the resulting PDF is saved under the public web root for retrieval.

Server-side fetch of arbitrary internal/cloud/file URLs (instance-metadata/IAM credential theft, internal service access, local file read) with exfiltration via the web-readable PDF. Reachable by any authenticated session — which, per ALD-01/02/03, an anonymous attacker can obtain.

Confirmed the inline isRemoteEnabled in AuditController is COMMENTED OUT (lines 675-688), but the ACTIVE path dispatches CreatePdfJob whose handle() genuinely sets isRemoteEnabled=true. PR set to L (not H) because admin access is not actually a barrier given ALD-01/03; Scope:Changed for cross-zone fetch.

The production env file (APP_ENV=production) is committed as a dated copy bypassing .gitignore, exposing the live MySQL credentials, the Gmail SMTP password for info@alist.ae, and the Laravel APP_KEY. The same DB password is a hardcoded fallback in config/database.php, leaking even without the .env file.

Full DB compromise if MySQL is reachable. SMTP password enables sending mail as info@alist.ae (phishing/BEC) and possibly broader Google account access. The APP_KEY enables forging signed cookies and decrypting/forging encrypted sessions, defeating authentication.

Confirmed all values present in .env_4-May-2020 and the fallback in config/database.php:53. File tracked and present since initial commit.

facade/ignition <2.5.2 has an unauthenticated RCE: the execute-solution endpoint plus php://filter log-file manipulation allows writing attacker-controlled content and including it. Exploitation requires only debug mode, which the committed production env enables.

Unauthenticated remote code execution as the web user on any internet-facing instance using this env. Combined with the committed DB/SMTP secrets, full data exfiltration and mail abuse follow. Mature weaponized exploits exist (Laravel-RCE / phpggc).

Confirmed ignition 1.16.3 in composer.lock and APP_DEBUG=true in committed env. Exploitability conditional on a live host (status unknown) — confidence 'confirmed' for the vulnerable configuration, realistic exposure gated on deployment.

Repo-root .config.json holds a complete Google OAuth2 credential set: client_id, client_secret, an AIza API key, and a long-lived offline refresh token. The refresh token plus client_id/secret mint fresh access tokens indefinitely with no user interaction. The unauthenticated /contacts route additionally echoes a refresh token to whoever completes the OAuth dance.

Programmatic read/modify of the A-List Google Contacts/People directory (influencer/vendor PII), OAuth client impersonation via the secret, and API-key abuse against enabled Google APIs (quota/billing).

Confirmed .config.json contents and that the file is tracked. /contacts echo confirmed in routes/web.php:53.

The app targets PHP 7.2 (EOL) and Laravel 6 (support ended), so the runtime, framework, and bundled Symfony 4.4/5.1 components receive no security fixes. Framework constraints cap all dependencies at long-unmaintained versions — a structural supply-chain risk.

Cumulative, ever-growing exposure to disclosed CVEs in runtime/framework/components with no upstream remediation path. Any newly weaponized PHP 7.2 / Laravel 6 / Symfony 4.4 bug is exploitable indefinitely on a deployed instance.

Confirmed versions in composer.json/composer.lock and ea-php72 handler references.

A 24.5 MB archive at the repo root is a full backup of a separate client Laravel app with its own .env (APP_KEY, Mailtrap MAIL_PASSWORD), composer.lock and bundled vendor tree, including an even older CVE-2021-3129-vulnerable Ignition (1.11.2). Per the permissive .htaccess (ALD-11) it is directly downloadable if any host serves the repo.

Leakage of a second project's APP_KEY (session/cookie forgery for that app) and Mailtrap mail credential, plus a ready-to-exploit second vulnerable codebase. Also bloats clone surface.

Confirmed via unzip: embedded .env present with APP_KEY/APP_DEBUG/Mailtrap MAIL_PASSWORD. Raw finding overstated DB_PASSWORD and PUSHER_APP_SECRET as populated — both are EMPTY in the embedded .env; corrected here. CVSS lowered to 8.6 / I:L accordingly.

The Laravel-without-docroot .htaccess rewrites only non-existent paths into /public/. Files that physically exist at the app root (.env_4-May-2020, .config.json, composer.lock, parhamandco.zip/.sql, error_log, info.php) are served verbatim because !-f skips them and there are no deny rules. composer.lock alone hands attackers the full SBOM.

Unauthenticated disclosure of the software bill of materials (removing the recon barrier for ALD-07/09/12) plus direct download of committed secret/backup/log files. Lowers attacker cost for every dependency CVE.

Confirmed .htaccess rewrite logic and that all named files are tracked at root. Exposure conditional on a live host.

Several directly/transitively used packages are pinned below patched versions and are reachable from controller/job code. dompdf 0.8.6 (CVE-2022-28368 RCE via CSS @font-face when rendering attacker-influenced HTML — directly relevant given ALD-05, and CVE-2021-3838 SSRF) is invoked from CreatePdfJob; phpspreadsheet 1.15.0 is exposed to XXE/formula-injection on user-supplied imports; guzzle/psr7 carry header-parsing/credential-leak-on-redirect CVEs; flysystem 1.1.3 has a path-traversal flaw. All are capped by the EOL framework.

Where attacker data reaches PDF generation, RCE/SSRF chains are plausible; spreadsheet import can yield XXE/file disclosure; HTTP-client CVEs can leak credentials on redirect. None can be cleanly patched in place.

Confirmed all versions in composer.lock and reachability of dompdf/phpspreadsheet from controllers/jobs. Related CVEs: CVE-2021-3838 (dompdf SSRF), CVE-2022-31090/31091 (guzzle), CVE-2022-24775 (psr7), CVE-2021-32708 (flysystem).

config/thirdparty.php (tracked) hardcodes four production Slack incoming-webhook URLs and a Monday.com API token with me:write scope; both are referenced by application code, confirming they are in-use. config/thirdparty.php_bkp commits an additional set.

Slack webhook leak permits posting spoofed/phishing messages into signup/approval/vendor channels. The Monday token permits read/modify of boards storing applicant PII via the Monday GraphQL API. Both usable directly from the committed repo.

Confirmed by reading config/thirdparty.php; the offers/signup/approve webhooks share one URL and one ('offers' original) is commented out — corrected to note the active set. CVSS lowered slightly (S:U, no integrity-of-other-component beyond messaging) vs raw 8.6.

A phpMyAdmin SQL dump committed at the repo root contains the bcrypt hash for admin@parhamandco.com and signup PII (names, emails, phones, Instagram handles, nationality).

The admin bcrypt hash can be cracked offline; a weak password yields admin login. The PII is a privacy/GDPR exposure and a phishing target list. Harvestable by anyone who clones the repo or downloads from a live host.

Confirmed bcrypt hash and PII rows present at parhamandco.sql:134 and surrounding.

VenueOfferController runs under the 'web' group (session/CSRF only) with no auth middleware. Its GET routes are state-changing yet take object IDs straight from request input. deleteOfferUsers deletes invitations, resets user-to-offer bindings, and emails cancellations for attacker-chosen IDs; proceedOffer/unBlockOffer similarly mutate state. No ownership or authentication check exists.

Unauthenticated integrity/availability impact on the offers subsystem: arbitrary cancellation/reassignment of offer claims, clearing user bindings (releasing/redistributing offer codes), and spamming arbitrary recipients with cancellation emails. Business-logic abuse + DoS against legitimate claims.

Confirmed VenueOfferController has no constructor/middleware and the routes are in the unauthenticated web group; deleteOfferUsers/proceedOffer bodies confirmed.

Public, unauthenticated routes resolve sensitive objects from URL/body identifiers obfuscated with Hashids instantiated using the default empty salt — publicly reversible/forgeable, effectively sequential integers in disguise. No endpoint verifies the requester owns the referenced user_id/offer_id. reviewSave persists a review on behalf of any user; /offerView uses base64('prive') as a guessable access token.

Horizontal IDOR: enumerate/disclose any influencer's review submissions and screenshots, forge reviews on behalf of arbitrary users, and view non-published offers via the static base64('prive') token. The default salt lets an attacker mint valid tokens for arbitrary IDs offline.

Confirmed new Hashids() with no salt at the cited sites and unauthenticated routes; base64('prive') and 'admin' gates confirmed in OfferController.php:48-67.

venueDropListAuto concatenates the unsanitized keyword into a single-quoted LIKE clause of a raw DB::select and returns the result as JSON, giving an in-band UNION/error-based extraction channel.

In-band UNION extraction of any table (PII in signups, credentials, offers) returned directly in the JSON response. Requires only a low-privilege authenticated session (obtainable via ALD-03).

Confirmed at FoodOffersController.php:1298-1300. CVSS adjusted to 7.6 (A:N — read/write but no direct availability impact in this query shape).

venueOffers concatenates request vid into a raw DB::select in an unquoted numeric context, so no quote-breakout is needed. Injected rows are iterated and reflected into HTML output, enabling UNION extraction and second-order XSS.

Arbitrary DB read via UNION/boolean/time-based injection; disclosure of all DB contents including PII and credentials. Low-privilege authenticated session required.

Confirmed at VenuesController.php:403-404.

listCategoryVenues concatenates request cid into a raw DB::select in an unquoted numeric context with no validation; rows are reflected as JSON, a clean in-band channel.

In-band UNION extraction of any table returned in JSON, including signups PII and credentials. Low-privilege authenticated session required.

Confirmed at AuditController.php:78-88.

userActionHistory concatenates request id into a raw DB::select in an unquoted numeric context. SELECT * plus downstream iteration makes UNION column-matching straightforward.

Arbitrary DB read via UNION/boolean/time-based injection, disclosing PII and credentials. Low-privilege authenticated session required.

Confirmed at AdminController.php:975-976.

Three phpinfo() scripts and two committed error_log files exist; the .htaccess rewrite serves existing files verbatim. APP_DEBUG=true in a production env yields verbose Laravel error pages.

phpinfo() discloses full PHP configuration, paths, and environment (which on cPanel can include secrets) — a complete recon map. Committed logs add filesystem layout and the cPanel account name; APP_DEBUG=true adds stack traces and is the precondition for the Ignition RCE (ALD-07).

Confirmed all three phpinfo files and APP_DEBUG=true. Overlaps ALD-07/ALD-11; kept distinct as the info-exposure cluster.

Numerous sensitive admin operations are GET routes; Laravel's CSRF middleware never inspects GET, and the session cookie has no SameSite restriction, so it is sent on cross-site GETs. An attacker page can force a logged-in admin's browser to perform these actions via <img> or auto-followed links.

An authenticated admin who visits an attacker page can be silently made to approve/decline accounts, block/suspend users, delete offers/codes, reset users, and approve venues — integrity/availability impact without consent.

Confirmed the GET routes in admin.php and same_site=null/secure=false in config/session.php. Realistic only against an authenticated admin (UI:R).

Stock Laravel password reset with no trusted-host pin and APP_URL=localhost: the framework derives reset-email URLs from the incoming Host header. With no host allowlist it accepts an arbitrary Host and emits reset links pointing to it.

An attacker who triggers a reset for a victim with a forged Host can produce a reset email whose link points to attacker-controlled host; if the victim clicks, the reset token leaks, enabling account (including admin) takeover. Also enables cache poisoning of host-derived links.

Likely (not confirmed): TrustProxies $headers is the broad ALL set BUT $proxies is null, so X-Forwarded-Host is NOT trusted by default — exploitation relies on the Host header path, which is real for stock reset with no TrustHosts. AC:H/UI:R reflects the click + Host-control requirement.

The committed production env sets APP_DEBUG=true, so Laravel renders Ignition/Whoops error pages with full stack traces, env vars (including the live DB/SMTP passwords in this same env), and paths on any unhandled exception — and satisfies the CVE-2021-3129 RCE precondition.

Unauthenticated disclosure of secrets, source paths, and stack traces on any error; with the EOL Ignition version, unauthenticated RCE (CVE-2021-3129).

Confirmed. Distinct from ALD-07 (the dependency vuln) and ALD-21 (the info-exposure cluster); this is the misconfiguration itself. CVSS 7.2 (info-disclosure with debug, RCE tracked separately in ALD-07).

The app uses non-cryptographic primitives as authorization tokens: daily offer access keyed on sha1(today's date) with no secret (publicly computable), the literal 'admin' as an admin flag in a URL segment, base64('prive') as a privilege gate, and default-salt Hashids (publicly reversible). Upload filenames use md5(time()).

Unauthenticated authorization bypass: forge sha1(date) to view restricted offer pages, set segment=admin to reach the admin-scoped query branch, supply base64('prive') for prive-tier offers. Default-salt Hashids enables ID enumeration/IDOR; predictable upload names allow guessing/overwriting.

Confirmed sha1(date) at VenueOfferController.php:113-115, base64('prive')/'admin' gates in OfferController/VenueOfferController, no-salt Hashids, and md5(time()) filename. OWASP recategorized to A07 (auth failures) as the core issue is weak authn/authz tokens, not pure crypto.

In the unauthenticated registerVendor handler, the client-supplied location_file_path is concatenated into public_path() for both source and destination of rename() with no basename()/realpath()/'..' filtering.

Arbitrary file move/overwrite within (and potentially outside) the web root by an unauthenticated attacker — defacement, overwriting application files, or relocating an uploaded file to a web-executable path as a step toward RCE. High integrity impact.

Confirmed at VendorSignupController.php:148-157, unauthenticated route in web.php:143. CVSS A set to N (move/overwrite is integrity, not direct availability); requires a pre-staged temp file so practical RCE is a chain.

The chat-agent area mixes three strategies: a custom middleware that only checks a session-key's presence, the proper auth:chat_agent guard on some routes, and no protection on getAjaxOfferDetails (line 38). The session-flag check is weaker than guard-based auth.

Under-authenticated access to chat-agent offer data via the unprotected getAjaxOfferDetails endpoint, and a fragile model prone to gaps as routes are added.

Confirmed: chat_agent.php:38 has no middleware; chatAgentAuthValidate only checks session::has(). Impact depends on what getAjaxOfferDetails returns — reads as a confidentiality issue.

The session cookie has no SameSite attribute and is not Secure by default. SameSite=null sends the cookie on cross-site requests (enabling the GET-based CSRF of ALD-22); Secure=false allows transmission over plaintext HTTP.

Facilitates CSRF (cookie attached cross-site) and session cookie interception over HTTP, contributing to session hijacking.

Confirmed all three values in config/session.php. Largely an amplifier for ALD-22.

A public GET endpoint invokes Artisan queue:work synchronously inside the web request, exposing internal operational functionality and enabling worker exhaustion.

Unauthenticated control over queue processing and a low-effort DoS vector (synchronous long-running jobs, including the 3600s-timeout CreatePdfJob, tie up PHP-FPM workers).

Confirmed at routes/web.php:105-108.

allow_url_include=On permits remote URL inclusion, amplifying any file-inclusion/SSRF sink. The app emits no security response headers and configures no HTTPS/HSTS; enable_dl=On further weakens the runtime.

Increases blast radius of inclusion/SSRF bugs (ALD-05) and exposes users to clickjacking, MIME-sniffing, and protocol downgrade/MITM. Low standalone severity.

Confirmed php.ini directives and absence of security headers.

Multiple public controllers build a whereRaw INTERVAL fragment by concatenating $offer->avail_days, read from venues.avail_days rather than parameterized. The source is currently a DB column, but no store path enforces strict integer validation, so the trust boundary is fragile.

If avail_days ever becomes attacker-influenceable, a stored payload would execute in the INTERVAL clause of these public queries (boolean/time-based blind SQLi on unauthenticated endpoints). Currently low/theoretical because the value is DB-managed.

Confirmed concatenation at OfferController.php:220 and the DB-sourced origin; theoretical because no current write path injects request data into avail_days.

The Instagram validation rule builds a cURL request from unsanitized user input with TLS verification disabled and redirect-following enabled. If wired into a validator, crafted input plus follow-redirects could coerce server-side requests; disabled TLS verification removes a defense. The rule is not currently referenced, so exploitability today is limited.

If connected to a form: partial SSRF / outbound request control and MITM exposure. Currently dormant, low immediate risk.

Confirmed Instagram.php contents and that the rule is not wired in; remains theoretical/dormant. Also note the rule has die()/echo debug statements that would break validation in practice.