{"repro_id":"REPRO-2026-00223","version":7,"title":"phpBB authentication bypass/account hijacking via OAuth login-link flow with arbitrary auth_provider=apache","repro_type":"security","status":"published","severity":"critical","description":"Authentication bypass in phpBB's UCP login-link flow. ucp.php?mode=login_link loads includes/ucp/ucp_login_link.php which accepts an attacker-controlled auth_provider query/POST parameter and calls $provider_collection->get_provider($request->variable('auth_provider','')). By setting auth_provider=apache, the apache auth provider's login() method is invoked. The apache provider (phpbb/auth/provider/apache.php) reads PHP_AUTH_USER from the HTTP Basic Authorization header, checks it matches the submitted username, looks up the user in the database, and returns LOGIN_SUCCESS without ever validating the password. session_create() is then called for the target user. Default auth_method=db installations are vulnerable out of the box; OAuth is not required. An unauthenticated attacker can obtain a valid session as any known user including administrators.","root_cause":"# Root Cause Analysis — CVE-2026-48611\n\n## Summary\n\nCVE-2026-48611 is a critical unauthenticated authentication-bypass in phpBB\n3.3.0–3.3.16 (and 4.0.0-a2). The UCP \"login-link\" flow\n(`ucp.php?mode=login_link`) lets an attacker choose which authentication\nprovider handles the login via a fully attacker-controlled `auth_provider`\nrequest parameter. By selecting the bundled `apache` provider and sending an\nHTTP Basic `Authorization` header that carries any existing username (e.g.\n`admin`), an unauthenticated remote attacker obtains a valid phpBB session as\nthat user — including administrators — **without knowing the password**. The\n`apache` provider trusts `PHP_AUTH_USER` from the Basic header and returns\n`LOGIN_SUCCESS` after a database lookup without ever validating the password,\nafter which `ucp_login_link` calls `$user->session_create()`. The flaw is\npresent in the **default** `auth_method=db` installation; OAuth does not need\nto be configured. Fixed in phpBB 3.3.17 (2026-06-06).\n\n## Impact\n\n- **Package/component affected:** `phpBB/includes/ucp/ucp_login_link.php`\n  (attacker-controlled provider selection) combined with\n  `phpBB/phpbb/auth/provider/apache.php` (password-less `login()`).\n- **Affected versions:** phpBB 3.3.0 through 3.3.16, and 4.0.0-a2. Default\n  `auth_method=db` boards are vulnerable out of the box.\n- **Risk level and consequences:** Critical (CVSS 9.8). A single unauthenticated\n  HTTP request hijacks any known account. Logging in as an administrator yields\n  full board control (ACP access, user management, extension installation,\n  persisted backdoors). Usernames are public on phpBB boards, so admin/moderator\n  accounts are trivially targetable.\n\n## Impact Parity\n\n- **Disclosed/claimed maximum impact:** Unauthenticated remote account\n  hijacking of arbitrary known accounts (including administrators) → full board\n  compromise; no password, no prior access, no user interaction.\n- **Reproduced impact from this run:** Full parity. Against a real running\n  phpBB 3.3.16 (Apache 2.4 + mod_php 8.2 + SQLite, default `auth_method=db`,\n  installed via the official CLI installer) a single unauthenticated POST to\n  `ucp.php?mode=login_link&auth_provider=apache&login_link_aikido=1` with\n  `Authorization: Basic admin:x` (password `x` deliberately wrong) returned a\n  `302` response that set the session cookie `phpbb3_..._u=2` (the\n  administrator account, `user_id=2`, `user_type=USER_FOUNDER`). Reloading\n  `index.php` with that stolen session rendered the page as the `admin` user\n  and showed the **Administration Control Panel** link (`adm/index.php`) — an\n  admin-only UI element — confirming a genuine administrator session. The same\n  request against phpBB 3.3.17 left the session as anonymous (`_u=1`) and\n  produced no admin session.\n- **Parity:** `full`.\n- **Not demonstrated:** N/A — the claimed impact (authz bypass / admin account\n  takeover) was demonstrated end-to-end on the real product.\n\n## Root Cause\n\nTwo cooperating defects form the exploit chain:\n\n1. **Attacker-controlled auth provider.** In `ucp_login_link::main()` the\n   provider is resolved from the request:\n   ```php\n   // phpBB/includes/ucp/ucp_login_link.php (3.3.16)\n   $provider_collection = $phpbb_container->get('auth.provider_collection');\n   $auth_provider = $provider_collection->get_provider($request->variable('auth_provider', ''));\n   ```\n   The `auth_provider` value is taken verbatim from the request (GET or POST),\n   so an attacker can force the use of **any** registered provider class under\n   `phpbb/auth/provider/`, not only the board's configured `auth_method`.\n\n2. **Password-less `apache` provider.** `phpbb/auth/provider/apache.php::login()`\n   decodes `PHP_AUTH_USER`/`PHP_AUTH_PW` from the HTTP Basic\n   `Authorization` header, requires that `PHP_AUTH_USER === $username`, looks\n   the user up in the database, and — for an active user — returns\n   `LOGIN_SUCCESS` **without comparing `PHP_AUTH_PW` to the stored password\n   hash**. This is intentional *only* when Apache itself is the authenticating\n   proxy (`.htpasswd`); the provider simply trusts the username the proxy\n   forwards. By driving this provider through the login-link flow, the\n   attacker's own HTTP client becomes the \"trusted proxy\" and supplies any\n   username it wants.\n\n   Back in `ucp_login_link::main()`, a `LOGIN_SUCCESS` result with no error\n   leads directly to:\n   ```php\n   $user->session_create($login_result['user_row']['user_id'], false, false, true);\n   $this->perform_redirect();\n   ```\n   i.e. a fully authenticated session for the chosen user is created and the\n   browser is redirected to the index — all from one unauthenticated POST.\n\nThe login-link gate (`get_login_link_data_array()` requiring a non-empty\n`login_link_*` GET parameter) is trivially satisfied with dummy data such as\n`login_link_aikido=1`, so it provides no meaningful protection.\n\n**Fix (phpBB 3.3.17, ticket/17659).** The login-link handling was moved out of\n`ucp.php`/`ucp_login_link.php` into a dedicated controller\n`phpbb/ucp/controller/oauth.php`. In `ucp.php` the `login_link` mode now\nredirects to that controller (`phpbb_redirect_to_controller(...)`), and the\ncontroller resolves the provider **without** the attacker-controlled argument:\n```php\n// phpBB/phpbb/ucp/controller/oauth.php (3.3.17), link_account()\n$auth_provider = $this->auth_collection->get_provider();   // no argument -> configured auth_method (db)\n```\nWith the default `db` provider, `login()` actually verifies the password hash,\nso the wrong password (`x`) is rejected and no session is created. The\n`auth_provider=apache` trick is therefore no longer reachable. Key commits in\n`release-3.3.16..release-3.3.17`: `12c4cf6f78`, `c05603cc3a`,\n`4a2962bfc8` (`[ticket/17659]` series — \"Add new oauth link controller\" /\n\"Make account linking work via controller\" / \"Move login linking for oauth to\ncontroller\").\n\n## Reproduction Steps\n\n1. **Script:** `bundle/repro/reproduction_steps.sh` (self-contained, idempotent;\n   run with `PRUVA_ROOT=<bundle dir> bash bundle/repro/reproduction_steps.sh`).\n2. **What it does:**\n   - Reuses (or creates) git worktrees of phpBB at `release-3.3.16`\n     (vulnerable) and `release-3.3.17` (fixed) from the durable project cache\n     mirror.\n   - Builds a Docker image per version on `php:8.2-apache` (gd/intl/zip\n     extensions, mod_rewrite, AllowOverride All) and runs the official phpBB\n     CLI installer (`install/phpbbcli.php install`) with a SQLite backend and an\n     `admin`/`adminadmin` founder account (`user_id=2`).\n   - Starts each image as a running Apache+mod_php service and sends the **real\n     exploit** through it (HTTP requests are issued from inside each container\n     against `127.0.0.1:80`, because the sandbox blocks host→container port\n     publishing; this still crosses the genuine Apache/PHP request boundary and\n     populates `PHP_AUTH_USER`/`PHP_AUTH_PW` via mod_php):\n     ```\n     POST /ucp.php?mode=login_link&auth_provider=apache&login_link_aikido=1\n     Authorization: Basic base64(admin:x)\n     Content-Type: application/x-www-form-urlencoded\n     login_username=admin&login_password=x&login=Login\n     ```\n   - Asserts the vulnerable build sets the session cookie `*_u=2` and that the\n     index page, loaded with the stolen session, shows the admin username and\n     the ACP link. Asserts the fixed build leaves the session anonymous\n     (`*_u=1`) for the same request (both via `ucp.php` and directly via the\n     new controller `/app.php/user/oauth/link_account`).\n3. **Expected evidence:** The vulnerable response is a `302 Found` whose\n   `Set-Cookie` headers include `phpbb3_...._u=2` and a `Location` to the\n   index; the fixed response is a `301` redirect to the controller (ucp.php\n   path) / a `200` login-link form with a `class=\"error\"` block and\n   `phpbb3_...._u=1` (controller path). The script exits `0` only when the\n   vulnerable build hijacks admin **and** the fixed build blocks it.\n\n## Evidence\n\n- `bundle/logs/reproduction_steps.log` — full annotated run log (two\n  consecutive successful runs).\n- `bundle/logs/vuln_exploit_response.txt` / `bundle/logs/vuln_setcookie_summary.txt`\n  — vulnerable 3.3.16 exploit response. Excerpt:\n  ```\n  HTTP/1.1 302 Found\n  Set-Cookie: phpbb3_c6ct2_u=1; ...; HttpOnly\n  Set-Cookie: phpbb3_c6ct2_u=2; ...; HttpOnly          <-- admin user_id=2\n  Location: http://localhost/index.php?sid=e7988db9...\n  ```\n- `bundle/repro/artifacts/vuln/index_with_session.html` — `index.php` loaded\n  with the stolen cookie; contains `username-coloured\">admin` and the\n  admin-only `Administration Control Panel` / `adm/index.php` link.\n- `bundle/repro/artifacts/vuln/cookies.txt` — Netscape cookie jar with\n  `phpbb3_..._u = 2`.\n- `bundle/logs/fixed_exploit_ctrl_response.txt` /\n  `bundle/logs/fixed_setcookie_summary.txt` — fixed 3.3.17 controller response.\n  Excerpt: only `Set-Cookie: phpbb3_9wg5u_u=1` (anonymous) and a\n  `<div class=\"error\">...not available. Please restart the login\n  process.</div>` block; no `_u=2`, no redirect to the index.\n- `bundle/repro/artifacts/fixed/exploit_ucp_response.txt` — fixed `ucp.php`\n  path returns `301 Moved Permanently` to\n  `/app.php/user/oauth/link_account?...` (no apache-provider login).\n- `bundle/repro/runtime_manifest.json` — runtime evidence manifest\n  (`entrypoint_kind=api_remote`, `service_started=true`,\n  `healthcheck_passed=true`, `target_path_reached=true`).\n- **Environment:** Docker `php:8.2-apache` (Apache/2.4.67, PHP/8.2.32,\n  mod_php), phpBB `release-3.3.16` and `release-3.3.17`, SQLite3 backend,\n  default `auth_method=db`, board installed via\n  `php install/phpbbcli.php install`.\n\n## Recommendations / Next Steps\n\n- **Patch immediately.** Upgrade every phpBB instance to 3.3.17 or later. This\n  is the only complete fix.\n- **Temporary workaround (pre-3.3.17, only if Apache/LDAP auth is unused):**\n  remove `phpbb/auth/provider/apache.php` and `phpbb/auth/provider/ldap.php`\n  from the board root, and disable OAuth in the ACP until upgraded (per the\n  phpBB team's urgent advisory).\n- **Defense-in-depth:** authentication providers must never be selectable from\n  untrusted request input; provider resolution should always use the\n  board-configured `auth_method`. The `apache` provider's trust model (proxy\n  authenticated the user) should be gated to boards that actually configure\n  Apache/LDAP front-auth, and should not be exposed through flows designed for\n  OAuth.\n- **Detection:** hunt request logs for `mode=login_link` together with\n  `auth_provider=apache` (in either query string or POST body); also watch for\n  the body-only variant where `mode=login_link` and `auth_provider=apache` are\n  in the POST body while the query string carries `login_link_*=1`.\n- **Testing:** add a regression test asserting that `ucp.php?mode=login_link`\n  never honors an attacker-supplied `auth_provider`, and that the `apache`\n  provider cannot grant `LOGIN_SUCCESS` without external-auth configuration.\n\n## Additional Notes\n\n- **Idempotency:** `reproduction_steps.sh` was executed twice consecutively;\n  both runs exited `0` with identical verdicts. The script reuses cached\n  worktrees and Docker images on subsequent runs (only container start/stop\n  and the HTTP exploit are re-executed), so re-runs complete in a few seconds.\n- **Surface match:** the claimed surface is `api_remote` (HTTP endpoint). The\n  proof drives the real Apache+mod_php endpoint `ucp.php` (and the fixed\n  controller) with the actual exploit request, satisfying the\n  `api_remote`/`endpoint` requirement; `runtime_manifest.json` records\n  `service_started`, `healthcheck_passed`, and `target_path_reached` all\n  `true`.\n- **Sandbox networking note:** host→container port publishing is blocked in\n  this environment, so the script issues exploit traffic from inside each\n  container via `docker exec curl http://127.0.0.1:80/...`. This still crosses\n  the genuine Apache + mod_php request boundary (PHP_AUTH_USER/PHP_AUTH_PW are\n  populated by mod_php from the `Authorization: Basic` header), and is\n  equivalent to an external attacker hitting the deployed forum over HTTP.\n- **Negative control:** the identical exploit request against 3.3.17 does not\n  create an admin session (`_u=1`), and `ucp.php?mode=login_link` is reduced to\n  a redirect to the new OAuth controller, confirming the patch closes the\n  attack path.\n","cve_id":"CVE-2026-48611","cwe_id":"CWE-305: Authentication Bypass by Primary Weakness","source_url":"https://nvd.nist.gov/vuln/detail/CVE-2026-48611","package":{"name":"phpbb/phpbb","ecosystem":"github","affected_versions":"phpBB 3.3.0 through 3.3.16 and 4.0.0-a2 (default configuration, auth_method=db)","fixed_version":"phpBB 3.3.17 released 2026-06-06"},"reproduced_at":"2026-07-04T07:16:02.352700+00:00","duration_secs":1329.0,"tool_calls":214,"handoffs":3,"total_cost_usd":4.8292754700000025,"agent_costs":{"coding":0.81274506,"hypothesis_generator":0.0147064,"judge":0.00781535,"repro":3.0407397899999995,"support":0.19053791999999997,"vuln_variant":0.7627309499999999},"cost_breakdown":{"coding":{"accounts/fireworks/routers/glm-5p2-fast":0.81274506},"hypothesis_generator":{"accounts/fireworks/models/glm-5p2":0.0147064},"judge":{"gpt-5.4-mini":0.00781535},"repro":{"accounts/fireworks/routers/glm-5p2-fast":3.0407397899999995},"support":{"accounts/fireworks/routers/glm-5p2-fast":0.19053791999999997},"vuln_variant":{"accounts/fireworks/routers/glm-5p2-fast":0.7627309499999999}},"quality":{"confidence":"high","idempotent_verified":false,"community_verifications":0},"environment":{"sandbox_image":"ghcr.io/n3mes1s/pruva-sandbox@sha256:8096b2518d6022e13d68f885c3b8ded6b4fe607098b1a1ccbfb99abc004d1dc1"},"published_at":"2026-07-04T07:16:03.394891+00:00","retracted":false,"artifacts":[{"path":"bundle/repro/reproduction_steps.sh","filename":"reproduction_steps.sh","size":15385,"category":"reproduction_script"},{"path":"bundle/repro/rca_report.md","filename":"rca_report.md","size":12408,"category":"analysis"},{"path":"bundle/vuln_variant/reproduction_steps.sh","filename":"reproduction_steps.sh","size":17305,"category":"reproduction_script"},{"path":"bundle/vuln_variant/rca_report.md","filename":"rca_report.md","size":15699,"category":"analysis"},{"path":"bundle/coding/proposed_fix.diff","filename":"proposed_fix.diff","size":1805,"category":"patch"},{"path":"bundle/ticket.md","filename":"ticket.md","size":1164,"category":"ticket"},{"path":"bundle/ticket.json","filename":"ticket.json","size":2207,"category":"other"},{"path":"bundle/AGENTS.repro.md","filename":"AGENTS.repro.md","size":508,"category":"documentation"},{"path":"bundle/docker/Dockerfile","filename":"Dockerfile","size":2350,"category":"other"},{"path":"bundle/docker/apache-site.conf","filename":"apache-site.conf","size":300,"category":"other"},{"path":"bundle/docker/install-config.yml","filename":"install-config.yml","size":755,"category":"other"},{"path":"bundle/repro/artifacts/vuln/exploit_response.txt","filename":"exploit_response.txt","size":837,"category":"other"},{"path":"bundle/repro/artifacts/vuln/cookies.txt","filename":"cookies.txt","size":349,"category":"other"},{"path":"bundle/repro/artifacts/vuln/index_with_session.html","filename":"index_with_session.html","size":15816,"category":"other"},{"path":"bundle/repro/artifacts/fixed/exploit_ucp_response.txt","filename":"exploit_ucp_response.txt","size":1417,"category":"other"},{"path":"bundle/repro/artifacts/fixed/cookies_ucp.txt","filename":"cookies_ucp.txt","size":349,"category":"other"},{"path":"bundle/repro/artifacts/fixed/exploit_ctrl_response.txt","filename":"exploit_ctrl_response.txt","size":11887,"category":"other"},{"path":"bundle/repro/artifacts/fixed/cookies_ctrl.txt","filename":"cookies_ctrl.txt","size":349,"category":"other"},{"path":"bundle/repro/runtime_manifest.json","filename":"runtime_manifest.json","size":1037,"category":"other"},{"path":"bundle/repro/validation_verdict.json","filename":"validation_verdict.json","size":1043,"category":"other"},{"path":"bundle/logs/reproduction_steps.log","filename":"reproduction_steps.log","size":2568,"category":"log"},{"path":"bundle/logs/vuln_exploit_response.txt","filename":"vuln_exploit_response.txt","size":837,"category":"other"},{"path":"bundle/logs/fixed_exploit_ctrl_response.txt","filename":"fixed_exploit_ctrl_response.txt","size":11887,"category":"other"},{"path":"bundle/logs/vuln_setcookie_summary.txt","filename":"vuln_setcookie_summary.txt","size":249,"category":"other"},{"path":"bundle/logs/fixed_setcookie_summary.txt","filename":"fixed_setcookie_summary.txt","size":235,"category":"other"},{"path":"bundle/logs/vuln_variant.log","filename":"vuln_variant.log","size":4431,"category":"log"},{"path":"bundle/logs/vv_vuln_v5_resp.txt","filename":"vv_vuln_v5_resp.txt","size":837,"category":"other"},{"path":"bundle/logs/vv_fixed_v5ctrl_resp.txt","filename":"vv_fixed_v5ctrl_resp.txt","size":11887,"category":"other"},{"path":"bundle/logs/vv_fixed_v1_register_resp.txt","filename":"vv_fixed_v1_register_resp.txt","size":12404,"category":"other"},{"path":"bundle/logs/vv_fixed_v3_resp.txt","filename":"vv_fixed_v3_resp.txt","size":11937,"category":"other"},{"path":"bundle/logs/vv_fixed_v4_resp.txt","filename":"vv_fixed_v4_resp.txt","size":9947,"category":"other"},{"path":"bundle/vuln_variant/artifacts/vuln/v5_cookies.txt","filename":"v5_cookies.txt","size":349,"category":"other"},{"path":"bundle/vuln_variant/artifacts/vuln/v5_cookies.txt.resp.txt","filename":"v5_cookies.txt.resp.txt","size":837,"category":"other"},{"path":"bundle/vuln_variant/artifacts/vuln/v5_index.html","filename":"v5_index.html","size":15822,"category":"other"},{"path":"bundle/vuln_variant/artifacts/vuln/v1_form_cookies.txt","filename":"v1_form_cookies.txt","size":349,"category":"other"},{"path":"bundle/vuln_variant/artifacts/vuln/v1_form_cookies.txt.resp.txt","filename":"v1_form_cookies.txt.resp.txt","size":544,"category":"other"},{"path":"bundle/vuln_variant/artifacts/vuln/v1_submit_cookies.txt","filename":"v1_submit_cookies.txt","size":349,"category":"other"},{"path":"bundle/vuln_variant/artifacts/vuln/v1_submit_cookies.txt.resp.txt","filename":"v1_submit_cookies.txt.resp.txt","size":12412,"category":"other"},{"path":"bundle/vuln_variant/artifacts/fixed/v5_ucp_cookies.txt","filename":"v5_ucp_cookies.txt","size":349,"category":"other"},{"path":"bundle/vuln_variant/artifacts/fixed/v5_ucp_cookies.txt.resp.txt","filename":"v5_ucp_cookies.txt.resp.txt","size":1417,"category":"other"},{"path":"bundle/vuln_variant/artifacts/fixed/v5_ctrl_cookies.txt","filename":"v5_ctrl_cookies.txt","size":349,"category":"other"},{"path":"bundle/vuln_variant/artifacts/fixed/v5_ctrl_cookies.txt.resp.txt","filename":"v5_ctrl_cookies.txt.resp.txt","size":11887,"category":"other"},{"path":"bundle/vuln_variant/artifacts/fixed/v1_form_cookies.txt","filename":"v1_form_cookies.txt","size":349,"category":"other"},{"path":"bundle/vuln_variant/artifacts/fixed/v1_form_cookies.txt.resp.txt","filename":"v1_form_cookies.txt.resp.txt","size":544,"category":"other"},{"path":"bundle/vuln_variant/artifacts/fixed/v1_submit_cookies.txt","filename":"v1_submit_cookies.txt","size":349,"category":"other"},{"path":"bundle/vuln_variant/artifacts/fixed/v1_submit_cookies.txt.resp.txt","filename":"v1_submit_cookies.txt.resp.txt","size":12404,"category":"other"},{"path":"bundle/vuln_variant/artifacts/fixed/v2_cookies.txt","filename":"v2_cookies.txt","size":349,"category":"other"},{"path":"bundle/vuln_variant/artifacts/fixed/v2_cookies.txt.resp.txt","filename":"v2_cookies.txt.resp.txt","size":1417,"category":"other"},{"path":"bundle/vuln_variant/artifacts/fixed/v3_cookies.txt","filename":"v3_cookies.txt","size":349,"category":"other"},{"path":"bundle/vuln_variant/artifacts/fixed/v3_cookies.txt.resp.txt","filename":"v3_cookies.txt.resp.txt","size":11937,"category":"other"},{"path":"bundle/vuln_variant/artifacts/fixed/v4_cookies.txt","filename":"v4_cookies.txt","size":349,"category":"other"},{"path":"bundle/vuln_variant/artifacts/fixed/v4_cookies.txt.resp.txt","filename":"v4_cookies.txt.resp.txt","size":9947,"category":"other"},{"path":"bundle/vuln_variant/artifacts/.resp.tmp","filename":".resp.tmp","size":9947,"category":"other"},{"path":"bundle/vuln_variant/runtime_manifest.json","filename":"runtime_manifest.json","size":945,"category":"other"},{"path":"bundle/vuln_variant/patch_analysis.md","filename":"patch_analysis.md","size":11597,"category":"documentation"},{"path":"bundle/vuln_variant/variant_manifest.json","filename":"variant_manifest.json","size":5646,"category":"other"},{"path":"bundle/vuln_variant/validation_verdict.json","filename":"validation_verdict.json","size":5167,"category":"other"},{"path":"bundle/vuln_variant/source_identity.json","filename":"source_identity.json","size":1948,"category":"other"},{"path":"bundle/vuln_variant/root_cause_equivalence.json","filename":"root_cause_equivalence.json","size":3082,"category":"other"},{"path":"bundle/logs/verify_fix.log","filename":"verify_fix.log","size":1268,"category":"log"},{"path":"bundle/logs/verify_build_patched.log","filename":"verify_build_patched.log","size":13524,"category":"log"},{"path":"bundle/coding/verify_artifacts/testA_response.txt","filename":"testA_response.txt","size":11873,"category":"other"},{"path":"bundle/coding/verify_artifacts/testA_cookies.txt","filename":"testA_cookies.txt","size":349,"category":"other"},{"path":"bundle/coding/verify_artifacts/testB_response.txt","filename":"testB_response.txt","size":837,"category":"other"},{"path":"bundle/coding/verify_artifacts/testB_cookies.txt","filename":"testB_cookies.txt","size":349,"category":"other"},{"path":"bundle/coding/verify_artifacts/testB_index_with_session.html","filename":"testB_index_with_session.html","size":15823,"category":"other"},{"path":"bundle/coding/verify_artifacts/control_response.txt","filename":"control_response.txt","size":837,"category":"other"},{"path":"bundle/coding/verify_artifacts/control_cookies.txt","filename":"control_cookies.txt","size":349,"category":"other"},{"path":"bundle/coding/verify_result.json","filename":"verify_result.json","size":762,"category":"other"},{"path":"bundle/coding/verify_fix.sh","filename":"verify_fix.sh","size":13482,"category":"other"},{"path":"bundle/coding/summary_report.md","filename":"summary_report.md","size":13058,"category":"documentation"}]}