Budibase, Gogs, Actual, skillctl, Nuxt, and automation boundary checks¶

Source: hourly offensive-security scan, 2026-06-22. Primary entries: GitHub advisories GHSA-jj36-r9w3-3pfh / CVE-2026-50136, GHSA-v7j5-vc4m-723w / CVE-2026-50132, GHSA-4q6h-8p4v-67vq / CVE-2026-48153, GHSA-c4v7-xg93-qf8g / CVE-2026-47267, GHSA-74p7-6h78-gw8p, GHSA-mqpr-49jj-32rc / CVE-2026-56357, GHSA-c9cv-mq2m-ppp3 / CVE-2026-56326, GHSA-9m6g-wc8r-q59c / CVE-2026-48170, and GHSA-ghmh-jhmj-wcmf. Late same-day updates added GHSA-35c4-rvc8-frhm / CVE-2026-50137, GHSA-rgvg-3wpc-h44p / CVE-2026-54351, GHSA-gfq7-5x4g-3xhf / CVE-2026-54353, GHSA-w7mq-r738-x278 / CVE-2026-54352, GHSA-wv27-2vqp-j7g5 / CVE-2026-52801, GHSA-pwx3-qcgw-vh7h / CVE-2026-52800, GHSA-p9f5-h3rx-j5qw / CVE-2026-52799, GHSA-jq8v-rmf6-65jw / CVE-2026-52798, GHSA-xqjm-27pc-rvwm / CVE-2026-50179, and GHSA-cq9c-6w48-qmfg / CVE-2026-49229.

June 23 Gogs updates added GHSA-744x-3838-5r56 / CVE-2026-52815, GHSA-c39w-43gm-34h5 / CVE-2026-52813, GHSA-6p9m-q3jp-47h4 / CVE-2026-52812, GHSA-89mr-xqfv-758m / CVE-2026-52811, GHSA-wmfg-5p4h-5fw3 / CVE-2026-52810, GHSA-268j-37xf-pp52 / CVE-2026-52808, GHSA-vcm5-gvmp-78mp / CVE-2026-52807, GHSA-qf6p-p7ww-cwr9 / CVE-2026-52806, GHSA-g2f5-gjr4-qjvm / CVE-2026-52805, GHSA-4565-r4x7-hg8j / CVE-2026-52804, and GHSA-xxhq-69mf-w8cr / CVE-2026-52802.

This batch is durable because each item exposes a repeatable operator workflow around trusted automation boundaries: low-code builders and public routes reaching stored cloud credentials, redirect-following webhook clients bypassing internal-host filters, skill-library metadata steering local filesystem and Git operations, framework navigation helpers normalizing URLs after validation, SCIM patch documents mutating process-global prototypes, and enrollment tokens becoming identity material after database exposure.

What changed¶

Adjacent GHSA-qc2x-6f54-m6h9 was processed but not promoted because the public impact is LAN-local mDNS cache corruption without a specific cross-privilege or data-access workflow. GHSA-hvqh-jw65-wcpq was processed without promotion as a standalone item because the autocomplete formatter XSS pattern is generic unless tied to a privileged suggestion source. Picklescan follow-up advisories GHSA-6w4w-5w54-rjvr, GHSA-6556-fwc2-fg2p, and GHSA-xp4f-hrf8-rxw7 were processed as additional unsafe-pickle gadget coverage for the existing ML archive-boundary workflow. GHSA-4j89-2c4f-44c6 and GHSA-xp79-5mx3-jx52 were processed without promotion because the public detail is Gogs denial of service without a data-access, authorization, or code-execution boundary. GHSA-5c3f-6486-3g7g was processed without promotion because password-reset lifetime drift is mainly an account-policy weakness unless paired with token capture. GHSA-p6qx-ghxm-389h was processed without a new page because the OctoPrint printer-output-to-admin-DOM pattern is useful but narrower than the Git forge wave; keep future printer/web-control items scoped to benign UI markers and never device-disrupting print actions.

Operator triage¶

1. Map who controls each trigger. Distinguish anonymous public callers, authenticated builders, organization owners, repository contributors, low-privilege app users, IdP provisioning clients, CSV importers, and holders of leaked database backups.
2. Separate validation-time from use-time. For SSRF, redirects, mirror URLs, ZIP paths, and URL helpers, record whether allowlists run before or after normalization, redirect following, DNS lookup, symlink resolution, and final request construction.
3. Use canary-only proofs. Disposable buckets, owned redirectors and DNS names, fake chat identities, scratch repositories, harmless attachments, marker notebooks, synthetic LFS blobs, inert branch-name commands, marker Git protocol pushes, inert webhook events, synthetic SCIM users, CSV rows, stale-session status checks, and fake enrollment tokens are sufficient.
4. Avoid sensitive endpoints. Do not target cloud metadata, production loopback panels, real datasource buckets, real chat accounts, real skill libraries, live workflow side effects, private customer attachments, financial exports, or production enrollment tokens.
5. Preserve role and topology evidence. Strong reports show route family, required auth role, datasource/workspace visibility, redirect or DNS-rebind chain, archive path resolution, process owner, and patched-vs-vulnerable comparisons.

Replayable validation boundaries¶

Budibase datasource, chat identity, and OAuth2 harness¶

• Preconditions: owned Budibase lab or explicit customer scope, disposable workspace, fake S3-compatible bucket, owned chat workspace identities, and one low-privilege builder/user account.
• For signed uploads, create a synthetic S3 datasource with throwaway credentials, then request a presigned URL from a session that should lack datasource access. Upload only an inert marker object to a disposable bucket/key.
• For chat identity handoff, create the attacker-side link token, then visit the handoff URL from a separate disposable authenticated victim browser profile. Evidence is the resulting mapping between two lab identities.
• For OAuth2 SSRF, submit token endpoint URLs pointing to owned callback collectors and owned redirectors. Capture callback timing and validation-envelope behavior only.
• For DNS-rebinding SSRF, configure an owned hostname that returns an allowed public IP for the validation lookup and a blocked lab canary IP for the later connection. Keep the second target under your control; do not use metadata, loopback admin panels, or production RFC1918 services.
• For public webhook trigger mass assignment, seed two disposable workspaces and a webhook whose only side effect is writing a marker to a canary table. Send a body containing an appId collision and record whether execution crosses workspace context.
• For PWA ZIP imports, include a symlink entry pointing to a synthetic outside-root marker and list that symlink path in icons.json; evidence is whether the served asset contains the marker bytes. Never point symlinks at .env, database files, cloud credentials, or user uploads.
• Negative controls: authentication and builder/table permission checks on attachment routes, CSRF/consent on chat-link handoff, URL allowlists applied after redirects, and no response-body leakage from failed OAuth2 validation.

Gogs webhook redirect SSRF harness¶

• Preconditions: scoped Gogs instance, disposable repository, permission to create/test webhooks, and an owned redirector domain.
• Create a webhook pointing to the owned redirector. Make the redirector return a 30x to a second owned URL that simulates a blocked host class without using real metadata or internal services.
• Positive evidence is the Gogs server following the redirect and reaching the second canary despite creation-time URL checks.
• Negative controls: redirect disabled or manually handled, final URL host/IP revalidated after every redirect, DNS rebinding resistance, and egress segmentation.

Gogs local import, organization, attachment, and notebook harness¶

• Preconditions: scoped Gogs lab, disposable organization, attacker/victim lab users, private scratch repositories, harmless attachments, and local scratch repositories containing marker commits only.
• Compare new-migration validation against mirror-settings edits with file:// or local-path repository values that should be blocked. Positive evidence is import of the marker repository through mirror settings when the new-migration path rejects it.
• For organization CSRF, create a disposable Owners team and test whether a GET request from the victim-owner browser adds the attacker user. Evidence is a role-change table for lab accounts only.
• For attachment authorization, upload a harmless marker attachment to a private repo, then request /attachments/:uuid as unauthenticated and unauthorized lab users. Capture status, content hash of the marker, and parent-object permissions.
• For notebook previews, commit an .ipynb whose Markdown contains a harmless click-only DOM marker link. Capture whether client-side re-rendering recreates a dangerous scheme after server sanitization.
• Negative controls: identical local-import validation on create and edit paths, CSRF tokens on all state-changing methods, parent-object authorization before attachment file open, and no client re-render after sanitized notebook insertion.

Gogs Git forge tenant, protocol, and merge harness¶

• Preconditions: isolated Gogs lab, disposable orgs/repos, attacker/victim lab users, a synthetic Git HTTP server, a synthetic LFS object corpus, and temporary filesystem marker directories owned by the lab process.
• For organization-team API disclosure, request GET /api/v1/orgs/:orgname/teams as unauthenticated and low-privilege users; record only route, status, and synthetic team metadata exposure.
• For org-name path traversal, create only scratch organizations and repositories whose resolved paths point at disposable temp directories. Evidence is path resolution or marker repository placement; do not overwrite real hooks, SSH keys, config, or service files.
• For LFS dedupe, seed a private lab repo with a harmless LFS marker blob, then attempt to bind the same OID from a second repo without uploading matching bytes. Evidence is whether the second repo can fetch the marker through its own authorization context.
• For repository file uploads, commit a parent-directory symlink to a disposable target, then upload a marker filename that exercises backslash/path cleanup. Capture whether the marker appears outside the work tree.
• For Git smart HTTP confusion, grant a collaborator read-only access, then send a receive-pack request whose query string claims service=git-upload-pack. Evidence is acceptance or rejection of a marker commit to a scratch repo.
• For repository settings API drift, compare write-level collaborator calls against UI-visible admin-only controls for issue tracker, wiki, and mirror-sync settings. Keep changes reversible and scoped to throwaway repos.
• For milestone DOM sinks, create a milestone with a harmless visible marker and test each issue page/dropdown that renders it; do not include credential theft or privileged action payloads.
• For rebase-merge command injection, use a lab-only branch/refname that can run an inert marker command if accepted, such as writing to a temp file. Never run shell payloads on shared or customer-hosted Gogs.
• For migration redirect SSRF, submit an owned public Git URL that redirects to a synthetic blocked-host Git server you control. Evidence is redirect following and import attempt metadata, not internal repository contents.
• For collaboration owner escalation, submit raw access-mode values from a repo-admin lab account and record role transitions for disposable users only.
• For redirect_to, use example.invalid or an owned benign destination to prove browser-normalized off-origin navigation from slash/backslash traversal inputs.
• Negative controls: namespace validation before filesystem writes, every path component checked for symlinks, LFS body hash verified even on dedupe hits, authorization keyed to the actual Git RPC endpoint, API routes requiring the same role as UI routes, branch names passed after -- or rejected before shell/Git execution, final migration URL validation after redirects, owner mode unreachable by collaborator APIs, and URL validation after browser-equivalent normalization.

skillctl hostile library harness¶

• Preconditions: scratch project, scratch skill library, fake outside-root marker files, and no real credentials or home-directory paths.
• Test .skills.toml source_sha values that look like Git flags and confirm whether the tool rejects them before invoking git ls-tree.
• Add FIFO, device, socket, and hardlink canaries to a malicious skill folder and verify the copy path rejects non-regular files instead of blocking, reading unbounded data, or preserving hardlink relationships.
• Exercise add --dest only against temp directories and confirm absolute paths or .. traversal cannot delete or replace outside-root markers.
• Capture command, version, resolved paths, before/after trees, and rejection messages.

Automation and identity-parser harnesses¶

• For n8n, send one unsigned fake GitHub webhook and one properly signed canary event to a lab workflow whose only action writes a harmless marker. Positive evidence is workflow execution without valid X-Hub-Signature-256.
• For Nuxt, build a route table covering /..//host, /.//host, encoded-dot variants, protocol-relative paths, and javascript: targets passed through navigateTo(..., { open }); capture only redirect locations or blocked decisions.
• For scim-patch, apply a PATCH with __proto__.skillz_canary=true to a disposable SCIM user in a same-process lab and verify whether unrelated plain objects inherit the marker.
• For nebula-mesh, seed a lab SQLite DB with a pending synthetic enrollment token and show whether reading the DB reveals a consumable raw token; stop before touching real overlay identities.

Actual CSV and stale-session harness¶

• Preconditions: owned Actual lab, OpenID multi-user mode when testing session revocation, disposable transactions, and two lab users.
• For CSV formula injection, import or edit transaction Payee, Notes, Account, or Category fields with inert spreadsheet formulas that reference only owned callback URLs or local markers, then export CSV and confirm whether formula metacharacters survive as the first character of a cell.
• For disabled-user session validation, log in as a disposable OpenID user, preserve the session token, disable the user as admin, then call a harmless authenticated endpoint with the old token. Evidence is route/status parity before and after disablement; do not access budgets, bank-sync data, or real transactions.
• Negative controls: formula-prefix neutralization on export, import-to-export round-trip tests, session validation checking the user enabled flag on every protected route, and session invalidation during account disablement.

Reporting notes¶

• Lead with the exact crossed boundary: public route to stored datasource credentials, attacker chat token to victim account identity, builder OAuth URL to server-side fetch, DNS-rebinding name to blocked fetch target, ZIP symlink to served asset bytes, mirror edit to local repository import, CSRF GET to organization ownership, attachment UUID to private file, notebook Markdown to same-origin DOM sink, CSV cell to spreadsheet formula, disabled account to still-valid session, webhook redirect to blocked host, skill metadata to Git/filesystem side effects, unsigned webhook to workflow execution, raw navigation string to normalized browser destination, SCIM JSON to process-global prototype, or database read to enrollment identity claim.
• Keep evidence boring and reversible: canary object keys, redirect and DNS logs, fake chat IDs, scratch path trees, inert workflow markers, route decision tables, synthetic SCIM properties, lab enrollment rows, marker repositories, harmless attachments, click-only DOM markers, CSV cells, and stale-token status codes.
• Do not include secrets, cloud metadata output, real customer files, private repository content, real bank/chat identities, live workflow payloads, or production database contents.

June 23 Budibase and Gogs follow-up updates¶

The June 23 GitHub Advisory Database wave added two adjacent items that belong with this boundary batch instead of separate pages:

• GHSA-8qv3-p479-cj62 / CVE-2026-54350: Budibase published-app query templates could accept anonymous NoSQL operator injection.
• GHSA-3w28-36p9-w929 / CVE-2026-52816: Gogs' unauthenticated .ipynb sanitizer accepted arbitrary data: URIs, adding another notebook-preview XSS sink next to the earlier stored .ipynb preview issue.

Operator value:

• Budibase public app endpoints should be tested for anonymous filter/query material to database selector semantics, not just stored datasource and webhook boundaries.
• Gogs notebook rendering should be tested across both authenticated repository preview paths and unauthenticated sanitizer/helper routes; dangerous schemes can reappear as same-origin DOM even when no private repo content is involved.

Safe validation boundaries:

1. For Budibase, seed a disposable public app with canary records and submit paired baseline and operator-shaped filters such as harmless $ne/comparison probes. Evidence should be result-count or canary-record selection differences only; do not dump real tables or stored datasource credentials.
2. For Gogs, upload or submit a synthetic notebook containing a harmless data: URI marker that proves scheme acceptance or DOM insertion. Keep the marker click-only or visually inert; do not include credential-access scripts or private notebook data.
3. Negative controls: query templates bind values as literals, operator keys are rejected or escaped, notebook URI schemes are allowlisted after final rendering, and sanitizer routes require the same repository/auth context as previews.

Adjacent GHSA-p6qx-ghxm-389h remains tracked but not promoted here because the OctoPrint suppressed-command notification XSS pattern is narrower unless paired with printer-admin workflow scope and benign UI markers.

July 21 Gitea migration, revocation, and branch-policy follow-up¶

Four Gitea advisories extend the Git-forge workflow beyond the analogous Gogs checks above:

Replayable Gitea lab matrix¶

1. Use Gitea 1.25.4 or another affected build and 1.27.0 as the fixed control. Create one private scratch repository, public and synthetic-local Git HTTP services, an owned redirector/callback, protected and unprotected branches, and disposable owner/writer/former-collaborator accounts.
2. Migration redirect: submit the owned public Git URL and redirect it only to the synthetic-local Git service. Capture the submitted URL, DNS/redirect chain, Git request paths, imported marker commit, and whether a pull mirror repeats the fetch. Compare git -c http.followRedirects=false, a direct blocked URL, and 1.27.0. Never point the redirect at metadata, loopback administration, or real internal repositories.
3. PR retargeting: require one approval from a designated reviewer on the protected branch. Obtain a harmless approval from a non-designated lab reviewer while the PR targets the unprotected branch, retarget it, and record the review's official, dismissed, and stale fields plus the marker-only merge decision. Do not merge executable code or touch a production branch.
4. Revocation residue: while the collaborator is authorized, star the private repo, log time on an issue whose title is a synthetic sentinel, and create a marker-only webhook. Revoke access, establish that direct repository access fails, then query only the two relationship endpoints and trigger one post-revocation canary issue event. Record field presence and callback receipt; do not include source, comments, credentials, or real issue bodies.
5. Report the boundaries separately: validated migration URL -> Git follows an unvalidated final destination, approval state computed for branch A -> retarget to protected branch B -> stale approval satisfies B, access revoked -> relationship API still returns synthetic private metadata, or webhook creator revoked -> future canary event still delivered.

The relationship-endpoint issue is metadata-only; do not describe it as repository-content access. The webhook result requires that the former collaborator created the hook while authorized. Package presence alone is not proof: preserve the route, role history, branch policy, callback ownership, and fixed-version decisions.

Late July 21 Gitea forge-control boundary wave¶

The next reviewed-advisory wave exposed a larger set of reusable Gitea checks. Treat these as boundary families rather than 42 disconnected alerts. The adjacent Accept-Language, SSH-key, NPM, Debian, and Arch package entries are availability-only and are intentionally not promoted.

Outbound fetch and transport trust¶

Token, session, OAuth, and visibility decisions¶

Repository, Actions, LFS, and artifact authorization¶

Attachments and metadata oracles¶

Consolidated lab sequence¶

1. Run a disposable Gitea instance with an owned DNS zone, redirector, mock IdP, Git server, artifact runner, reverse proxy, and two-user/two-organization repository fixture. Put only markers in repos, LFS, releases, attachments, feeds, OAuth claims, and Actions artifacts.
2. Preserve four independent dimensions for every test: principal (anonymous/user/token/deploy key/job), route or protocol, parent resource, and final sink. Change one dimension at a time.
3. For outbound fetches, capture submitted URL, validation answers, redirect chain, re-resolution, final owned address, and response-retention behavior. Never point at cloud metadata, loopback administration, cluster APIs, or real internal repositories.
4. For token tests, record auth method, original scope/public-only flag, route category, ordinary user RBAC, returned marker fields, and any newly minted token's exact scope. Redact and revoke every token after the run.
5. For forge objects, use two repositories whenever possible. Capture object owner, parent repository, caller permission, global ID/UUID/OID, authorization decision, and before/after state. A known object identifier is a precondition where the advisory requires one; do not brute-force it.
6. For Actions and LFS, use marker-only workflows and blobs. Never place CI secrets, cloud credentials, source code, package tokens, or production artifacts in the fixture.
7. Report each boundary narrowly: SSRF classifier/redirect/re-resolution, token confinement, stale session, cross-parent object authorization, workflow-approval binding, or alternate API/UI control path. Do not combine unrelated transitions into an unproven full-account or host-compromise chain.

Final July 21 Gitea authentication, visibility, and lifecycle wave¶

Thirteen adjacent advisories extend the consolidated fixture above. They are grouped by state transition so operators can reuse one lab instead of treating each route as a disconnected alert.

Consolidated transition matrix¶

1. Start from Gitea 1.26.2 where applicable and the stated fixed version. Use disposable accounts, one fake IdP, public/private organizations, paired parent/fork repositories, an owned forge/HTTP listener, marker Actions runs, fake webhook credentials, and one synthetic TOTP seed.
2. Capture principal, credential form/scope, route or protocol, resource state before/after, and returned marker fields independently. For visibility bugs, establish direct-resource denial before testing relationship or aggregate routes.
3. Treat web/API, org/repo, and initial-use/later-use paths as paired controls: web vs API privatization, organization vs repository Actions, normal vs Basic TOTP, full vs public-only PAT, and direct parent read vs fork synchronization.
4. For the multi-ref push, use only non-production marker refs and preserve the ref order plus per-ref permission decision. Stop once the unauthorized marker ref is accepted; never force-update real protected branches.
5. Keep impact narrow. Public-only PAT findings retain the user's ordinary membership; notification/watch/fork findings depend on prior access or a prior public state; webhook secret exposure requires an administrative peer; migration fetches require the migration/import path.

Report these as one-time code -> replayed authentication, token flag -> route-family omission, migration metadata -> unfiltered secondary fetch, write-only webhook secret -> peer-admin API response, aggregate org API -> private child metadata, visibility transition -> stale relationship, disabled local account -> OAuth callback reactivation, single-branch grant -> cached multi-ref write, or public-era fork -> private-era commit synchronization. Do not combine them into an unproven account-takeover or host-compromise chain.

July 24 Budibase identity, role, metadata, and SQL follow-up¶

Five Budibase advisories add a reusable tenant-control matrix:

Run the identity and role cases as a two-user/two-app decision table. Capture caller account, session-bound account, body target, app header, current role, requested grant, response, and before/after server state. Keep fake OAuth values out of screenshots and revoke every lab key.

For SQL validation, grant the datasource user access only to a scratch schema. Start with a quote/error probe, then a boolean result-count differential, and use a stacked canary SELECT only if the exact route concatenates untrusted input. Never use DROP, DELETE, GRANT, file-write functions, sleep-heavy payloads, or production datasource credentials.

Late July 24 Budibase datasource, identity, and automation wave¶

The next Budibase wave belongs in the same two-user/two-app fixture:

Preserve each precondition independently: AI enabled, datasource type, BASIC/builder role, public-query publication, same-app co-builder, configured trusted IdP, or known datasource ID. Do not collapse the wave into a generic “Budibase compromise.” Strong reports name the exact transition: parameter string to MongoDB object, validated DNS answer to independently resolved dial, datasource credential to alternate authority, app-wide test channel to another builder, or identity claim/handoff to the wrong local user.

August 27 attachment signed-URL datasource-credential minting follow-up¶

GHSA-6x9p-4r67-5gjx / CVE-2026-54356 (@budibase/server ≤ 3.38.1) extends the existing "BASIC users can obtain S3 upload URLs for caller-selected buckets" boundary with a sharper transition: a low-privilege published-app BASIC user can mint S3 pre-signed PUT URLs for attacker-chosen bucket/key using the workspace datasource's stored server-side credentials.

• Endpoint: POST /api/attachments/:datasourceId/url
• Caller controls: bucket, key
• Returns: signedUrl, publicUrl

Because the signature is produced from the datasource's server-side S3 credentials, the minted URL writes to the attacker-chosen object destination under that credential's access — the workspace's S3 identity, not the caller's. This is the "datasource credential to alternate authority" transition in its clearest form: the endpoint hands a bearer-capable URL to a role that should not control object destinations.

Check¶

1. Lab: Budibase with an S3 datasource holding valid (lab) credentials. Two roles: an admin who creates/publishes the app and a BASIC published-app user.
2. As the BASIC user, POST /api/attachments/<datasourceId>/url with a bucket/key naming a disposable bucket/key the tester controls. Secure result: destination confined to the app's attachment prefix or the request is rejected. Vulnerable result: a signedUrl that PUTs the canary to the attacker-chosen key.
3. Prove only with a marker object in a disposable bucket. Do not write public executable objects, do not target host/config/credential paths, and do not exfiltrate via publicUrl of real data.

Report it as BASIC published-app role -> POST /api/attachments/:datasourceId/url -> caller-chosen bucket/key -> datasource-credential S3 signed PUT, distinct from the earlier caller-selected-bucket finding and from the REST-URL re-resolution findings.