Gogs proxy-auth, OpenCTI ingestion SSRF, motionEye file-read, and Paymenter upload boundary checks¶

Source: hourly offensive-security scan, 2026-06-22. Primary entries: GitHub advisories GHSA-w6j9-vw59-27wv / CVE-2026-25119, GHSA-ffm6-vvph-g5f5 / CVE-2026-21887, GHSA-4mvw-j8r9-xcgc / CVE-2024-37155, GHSA-g9fx-5r4h-pcw3 / CVE-2026-31978, GHSA-rhgp-6wq6-9j67 / CVE-2026-32315, GHSA-5pm9-r2m8-rcmj / CVE-2025-58048, GHSA-r3cw-c95m-wfh9 / CVE-2026-46488, GHSA-x93q-x9pc-w5hw / CVE-2026-44585, GHSA-rv89-wch8-c574 / CVE-2026-44584, GHSA-7wwh-xcc3-9fcg / CVE-2026-44583, and follow-up GHSA-5q4q-834j-g8g4 / CVE-2026-47198.

This batch is durable because the advisories share repeatable operator workflows: reverse-proxy identity headers crossing from the public client into application authentication, ingestion URLs becoming server-side requests, GraphQL introspection filters relying on brittle query formatting, media-preview paths reaching files outside a camera media root, local world-readable configuration exposing password hashes for chained validation, and authenticated attachments crossing into a public/executable storage path.

What changed¶

Adjacent GHSA-3qq3-668m-v9mj was processed but not promoted as a standalone workflow because the public details center on repository/wiki file-listing denial of service via Git pathspec parsing. Revisit it only if paired with an authorization, disclosure, or durable parser-differential path beyond availability impact.

Operator triage¶

1. Map deployment topology before testing. For Gogs, identify whether the app is reachable directly behind the reverse proxy, whether reverse-proxy auth is enabled, and which header name is configured. Do not assume X-WEBAUTH-USER if the deployment changed the header.
2. Separate direct-client, proxy, and server-side reachability. SSRF and proxy-auth bypasses depend on route placement. Record whether a request was sent to the public edge, the internal app listener, or an application feature that performs the outbound request.
3. Use owned canaries only. Callback domains, fake users, synthetic GraphQL tenants, temporary media files, and harmless upload markers are enough. Do not read production config, customer camera media, .env files, cloud metadata, or internal service responses.
4. Prove the boundary, not maximum impact. A canary session created by a forged proxy header, a blind callback from OpenCTI, a schema field disclosed by bypassed introspection, or an inert uploaded marker served with executable handling is sufficient for a report.
5. Chain only inside an approved lab. motionEye config readability plus preview traversal may form useful chains, but cracking hashes, reusing camera credentials, or reading unrelated files requires explicit authorization and a disposable environment.

Replayable validation boundaries¶

Reverse-proxy authentication header harness¶

• Preconditions: written permission to test the Gogs deployment, a disposable low-privilege account, and confirmation that reverse-proxy authentication is expected in scope.
• Send a baseline unauthenticated request to a harmless authenticated route, then repeat with the configured proxy-auth header set to the disposable username.
• Test both paths separately: through the public reverse proxy and, if in scope, directly to the backend listener or service port.
• Positive evidence is an authenticated response, user auto-creation, or session state for the disposable account when the request did not traverse a trusted identity proxy.
• Negative controls: Gogs 0.14.3+, backend listener not externally reachable, edge strips identity headers from clients, app validates source proxy, and auto-registration is disabled or scoped.

OpenCTI ingestion SSRF and GraphQL introspection harness¶

• Create a lab OpenCTI tenant and a canary HTTP endpoint under an owned domain.
• Submit ingestion/import/enrichment URLs that should be rejected by policy and one allowed canary URL. For redirect tests, keep the redirect target owned; do not point at cloud metadata or production internal services.
• For semi-blind SSRF, record only callback timing, source IP, method, path, and headers that do not include secrets.
• For introspection controls, compare a normal introspection query with compacted, no-whitespace, alias, fragment, and line-ending variants. Capture schema-field presence for lab objects only.
• Negative controls: URL parser canonicalization before fetch, scheme and host allowlists applied after redirects, egress isolation, and GraphQL validation rules rather than regex-only query matching.

motionEye media and configuration harness¶

• Use a disposable camera/media root with a synthetic outside-root marker readable by the motionEye lab process.
• Compare download/content routes and preview/thumbnail routes with the same encoded traversal filename matrix, including %2F-encoded separators and absolute-path variants, without targeting real files.
• Check file permissions on lab motion.conf and camera-*.conf; report only whether non-privileged local users can read synthetic @admin_password or camera-setting markers.
• If validating cookie authentication, use a lab admin hash created for the test and set only meye_username / meye_password_hash canaries in a fresh browser profile. Positive evidence is access to a harmless lab page, never camera streams or production settings.
• For action endpoints, use only harmless actions against a disposable camera profile: status-only checks, snapshot markers, or synthetic action-script markers that write under a temp directory. Do not move real PTZ cameras, start/stop production recording, trigger alarms, or run host commands.
• For restore or chain testing, use a fully isolated motionEye lab with synthetic archives and config files. Evidence should show path/auth/control-flow reachability and temp markers only; never upload web shells, read real config, crack hashes, or alter production camera settings.
• Negative controls: canonical path containment before every open/delete/preview path, rejection of absolute paths before os.path.join(), authentication decorators on every action/control route, config restore path sanitization, signatures derived from non-reusable secrets instead of stored password hashes, and 0600 config permissions owned by the service user.

Paymenter attachment serving harness¶

• Use a disposable low-privilege customer/support account and upload benign files only: text markers, image polyglots without executable content, and extension/MIME mismatch canaries.
• Record where the attachment is stored, the public URL shape, response headers, and whether the server treats the file as a download or active content.
• Do not upload web shells, execute server-side code, read .env, or touch production customer tickets.
• Negative controls: random outside-webroot storage, forced download headers, extension allowlists, content sniffing disabled, and route authorization on attachment retrieval.

Paymenter service-reference, verification, and webhook SSRF harness¶

• Seed two disposable customer accounts with distinct services and create tickets while changing only the service identifier. Evidence is whether a ticket references the other account's service; do not access or alter real customer services.
• Verify an account with an owned inbox, change the email to a second owned canary address, and record whether the verified flag resets or requires re-confirmation.
• Send PayPal webhook requests with PAYPAL-CERT-URL pointed only at an owned callback collector. Capture method, path, source IP, and nonsensitive headers; never use cloud metadata, loopback admin panels, or internal production hosts.
• Negative controls: ownership checks on every service ID, verification state bound to the current email value, webhook signature validation before fetch, and certificate URL allowlists pinned to PayPal-controlled hosts.

Paymenter checkout configuration injection harness¶

• Preconditions: Paymenter lab or explicitly scoped staging tenant, disposable customer account, non-billable product, and a server extension whose provisioning parameters can be inspected without creating production resources.
• Start with a normal checkout URL and record the expected config keys emitted by the extension's getCheckoutConfig() method.
• Add undefined URL/query keys under the Livewire config alias that should not be customer-controlled, using inert values such as skillz_plan_marker, low-risk quota labels, or a test package identifier.
• Complete only a disposable checkout flow and inspect the resulting service properties and provisioning request in the lab.
• Positive evidence is an undefined user-supplied key stored on the service or prioritized over an administrator-defined extension setting during provisioning.
• Negative controls: strict allowlists for URL-writable checkout keys, validation and discard of undefined config entries before persistence, server-side plan/resource derivation during provisioning, and audit logs that distinguish customer-selected options from administrator policy.

Paymenter credit race harness¶

• Preconditions: isolated Paymenter lab or explicitly scoped staging tenant, disposable customer, fake credit balance, and at least two non-billable invoices whose combined total exceeds the disposable credit.
• Establish the single-request baseline: one invoice paid with credit should reduce the balance and leave insufficient credit for the second invoice.
• Send two payment requests concurrently against separate invoices using the same customer session. Keep concurrency low and bounded, for example two to five synchronized requests, and stop as soon as the boundary is proven.
• Positive evidence is a before/after ledger showing the same starting credit satisfied more invoice value than should be possible, paired with request timestamps and invoice IDs from the lab.
• Do not test against production credits, real payment methods, live provisioning, or customer invoices. If the application triggers provisioning on paid invoices, use a fake product/provider that records an inert canary only.
• Negative controls: the lock is inside one database transaction, balance read and write are atomic, idempotency keys prevent duplicate settlement, and invoice state transitions are conditional on the current unpaid state.

Reporting notes¶

• State the crossed boundary precisely: client header to trusted reverse-proxy identity, ingestion URL to server-side request, GraphQL query text to schema-introspection policy, media preview path to outside-root file read, local config/hash to cookie-authenticated session, support attachment to executable public storage, customer service ID to support-ticket reference, old email verification to new address, webhook certificate URL to server-side fetch, checkout URL parameter to privileged provisioning property, or concurrent credit payment to non-atomic invoice settlement.
• Evidence should be boring: route matrices, canary callbacks, synthetic users, harmless uploaded markers, path-resolution tables, and redacted headers.
• Avoid mitigation-first framing; lead with reachability, preconditions, exact trust boundary, and canary impact within the authorized environment.