#web

### Problem Local platform users who can write to TYPO3’s mail‑file spool directory can craft a file that the system will automatically deserialize without any class restrictions. This flaw allows an attacker to inject and execute arbitrary PHP code in the public scope of the web server. The vulnerability is triggered when TYPO3 is configured with `$GLOBALS['TYPO3_CONF_VARS']['MAIL']['transport_spool_type'] = 'file';` and a scheduler task or cron job runs the command `mailer:spool:send`. The spool‑send operation performs the insecure deserialization that is at the core of this issue. ### Solution Update to TYPO3 versions 10.4.55 ELTS, 11.5.49 ELTS, 12.4.41 LTS, 13.4.23 LTS, 14.0.2 that fix the problem described. ### Credits Thanks to Vitaly Simonovich for reporting this issue, and to TYPO3 security team members Elias Häußler and Oliver Hader for fixing it. ### References * [TYPO3-CORE-SA-2026-004](https://typo3.org/security/advisory/typo3-core-sa-2026-004)

### Summary A TOCTOU race condition vulnerability allows a user to exceed the set number of active tunnels in their subscription plan. ### Details Affected conponent: `apps/web/src/routes/api/tunnel/register.ts` - `/tunnel/register` endpoint code-: ```ts // Check if tunnel already exists in database const [existingTunnel] = await db .select() .from(tunnels) .where(eq(tunnels.url, tunnelUrl)); const isReconnection = !!existingTunnel; console.log( `[TUNNEL LIMIT CHECK] Org: ${organizationId}, Tunnel: ${tunnelId}`, ); console.log( `[TUNNEL LIMIT CHECK] Is Reconnection: ${isReconnection}`, ); console.log( `[TUNNEL LIMIT CHECK] Plan: ${currentPlan}, Limit: ${tunnelLimit}`, ); // Check limits only for NEW tunnels (not reconnections) if (!isReconnection) { // Count active tunnels from Redis SET ...

### Summary This vulnerability allows a user i.e a free plan user to get more than the desired subdomains due to lack of db transaction lock mechanisms in `https://github.com/akinloluwami/outray/blob/main/apps/web/src/routes/api/%24orgSlug/subdomains/index.ts` ### Details - The affected code-: ```ts //Race condition const [subscription] = await db .select() .from(subscriptions) .where(eq(subscriptions.organizationId, organization.id)); const currentPlan = subscription?.plan || "free"; const planLimits = getPlanLimits(currentPlan as any); const subdomainLimit = planLimits.maxSubdomains; const existingSubdomains = await db .select() .from(subdomains) .where(eq(subdomains.organizationId, organization.id)); if (existingSubdomains.length >= subdomainLimit) { return json( { error: `Subdomain limit reached. The ${currentPlan} plan allows ${subdom...

### Problem Backend users who had access to the recycler module could delete arbitrary data from any database table defined in the TCA - regardless of whether they had permission to that particular table. This allowed attackers to purge and destroy critical site data, effectively rendering the website unavailable. ### Solution Update to TYPO3 versions 10.4.55 ELTS, 11.5.49 ELTS, 12.4.41 LTS, 13.4.23 LTS, 14.0.2 that fix the problem described. ### Credits Thanks to Sven Jürgens and Daniel Windloff for reporting this issue, and to TYPO3 security team member Elias Häußler for fixing it. ### References * [TYPO3-CORE-SA-2026-003](https://typo3.org/security/advisory/typo3-core-sa-2026-003)

### Problem Backend users with access to the redirects module and write permission on the `sys_redirect` table were able to read, create, and modify any redirect record - without restriction to the user’s own file‑mounts or web‑mounts. This allowed attackers to insert or alter redirects pointing to arbitrary URLs - facilitating phishing or other malicious redirect attacks. ### Solution Update to TYPO3 versions 10.4.55 ELTS, 11.5.49 ELTS, 12.4.41 LTS, 13.4.23 LTS, 14.0.2 that fix the problem described. ### Credits Thanks to Georg Dümmler for reporting this issue, and to TYPO3 security team member Elias Häußler for fixing it. ### References * [TYPO3-CORE-SA-2026-002](https://typo3.org/security/advisory/typo3-core-sa-2026-002)

### Problem By exploiting the `defVals` parameter, attackers could bypass field‑level access checks during record creation in the TYPO3 backend. This gave them the ability to insert arbitrary data into prohibited exclude fields of a database table for which the user already has write permission for a reduced set of fields. ### Solution Update to TYPO3 versions 10.4.55 ELTS, 11.5.49 ELTS, 12.4.41 LTS, 13.4.23 LTS, 14.0.2 that fix the problem described. ### Credits Thanks to Daniel Windloff for reporting this issue, and to TYPO3 core & security team member Benjamin Franzke for fixing it. ### References * [TYPO3-CORE-SA-2026-001](https://typo3.org/security/advisory/typo3-core-sa-2026-001)

### Summary A malicious website can abuse the server URL override feature of the OpenCode web UI to achieve cross-site scripting on `http://localhost:4096`. From there, it is possible to run arbitrary commands on the local system using the `/pty/` endpoints provided by the OpenCode API. ### Code execution via OpenCode API - The OpenCode API has `/pty/` endpoints that allow spawning arbitrary processes on the local machine. - When you run `opencode` in your terminal, OpenCode automatically starts an HTTP server on `localhost:4096` that exposes the API along with a web interface. - JavaScript can make arbitrary same-origin `fetch()` requests to the `/pty/` API endpoints. Therefore, JavaScript execution on `http://localhost:4096` gets you code execution on local the machine. ### JavaScript execution on localhost:4096 The markdown renderer used for LLM responses will insert arbitrary HTML into the DOM. There is no sanitization with DOMPurify or even a CSP on the web interface to pre...

*Previously reported via email to support@sst.dev on 2025-11-17 per the security policy in [opencode-sdk-js/SECURITY.md](https://github.com/sst/opencode-sdk-js/blob/main/SECURITY.md). No response received.* ### Summary OpenCode automatically starts an unauthenticated HTTP server that allows any local process—or any website via permissive CORS—to execute arbitrary shell commands with the user's privileges. ### Details When OpenCode starts, it spawns an HTTP server (default port 4096+) with no authentication. Critical endpoints exposed: - `POST /session/:id/shell` - Execute shell commands (`server.ts:1401`) - `POST /pty` - Create interactive terminal sessions (`server.ts:267`) - `GET /file/content?path=` - Read arbitrary files (`server.ts:1868`) The server is started automatically in `cli/cmd/tui/worker.ts:36` via `Server.listen()`. No authentication middleware exists in `server/server.ts`. The server uses permissive CORS (`.use(cors())` with default `Access-Control-Allow-Origin: ...

### Impact Within Umbraco Forms, configuring a malicious URL on the Webservice data source can result in Remote Code Execution. This affects all Umbraco Forms versions running on .NET Framework (up to and including version 8). ### Patches The affected Umbraco Forms versions are all End-of-Life (EOL) and not supported anymore, hence no patches will be released. Upgrading to any of the currently supported versions (v13, v16 or v17) is recommended. ### Workarounds If none of the configured Forms data sources uses the Webservice type, it can be safely excluded by adding the following code to the application. This will completely remove the option to select/use this data source within the Backoffice and thereby mitigate the vulnerability. ```c# using Umbraco.Core.Composing; using Umbraco.Forms.Core.Providers; using Umbraco.Forms.Core.Providers.DatasourceTypes; internal sealed class RemoveFormsWebserviceDataSourceTypeComposer : IUserComposer { public void Compose(Composition composit...

### Impact Gin-vue-admin <= v2.8.7 has a path traversal vulnerability in the breakpoint resume upload functionality. Attacker can upload any files on any directory. Path traversal vulnerabilities occur when a web application accepts user-supplied file paths without proper validation, allowing attackers to access or write files outside the intended directory. In the breakpoint_continue.go file, the MakeFile function accepts a fileName parameter through the /fileUploadAndDownload/breakpointContinueFinish API endpoint and directly concatenates it with the base directory path (./fileDir/) using os.OpenFile() without any validation for directory traversal sequences (e.g., ../). Notably, while the related makeFileContent function in the same file properly validates the fileName parameter by checking for .. sequences, the MakeFile function lacks this security control, indicating an inconsistent security implementation. An **attacker with file upload privileges (role ID 888 - super administ...