Nixpkgs security tracker

Login with GitHub
⚠️ You are using a production deployment that is still only suitable for demo purposes. Any work done in this might be wiped later without notice.

Automatically generated suggestions

to slate a suggestion for refinement.

to mark a suggestion as irrelevant and log the reason.

View:
Compact
Detailed
created 1 month, 4 weeks ago Activity log
  • Created suggestion
Svelte vulnerable to XSS during SSR with contenteditable `bind:innerText` and `bind:textContent`

Svelte performance oriented web framework. Prior to version 5.53.5, the contents of `bind:innerText` and `bind:textContent` on `contenteditable` elements were not properly escaped. This could enable HTML injection and Cross-Site Scripting (XSS) if rendering untrusted data as the binding's initial value on the server. Version 5.53.5 fixes the issue.

Affected products

svelte
  • ==< 5.53.5

Matching in nixpkgs

Package maintainers

created 1 month, 4 weeks ago Activity log
  • Created suggestion
DIscourse has DM communication-preference bypass when adding members

Discourse is an open source discussion platform. Prior to versions 2025.12.2, 2026.1.1, and 2026.2.0, DM communication-preference bypass when adding members via `Chat::AddUsersToChannel` — a user could add targets who have blocked/ignored/muted them to an existing DM channel, bypassing per-recipient PM restrictions that are enforced during DM channel creation. Versions 2025.12.2, 2026.1.1, and 2026.2.0 patch the issue. No known workarounds are available.

Affected products

discourse
  • ==>= 2026.2.0-latest, < 2026.2.0
  • ==< 2025.12.2
  • ==>= 2026.1.0-latest, < 2026.1.1

Matching in nixpkgs

Package maintainers

Permalink CVE-2026-27457
4.3 MEDIUM
  • CVSS version: 3.1
  • Attack vector (AV): NETWORK
  • Attack complexity (AC): LOW
  • Privileges required (PR): LOW
  • User interaction (UI): NONE
  • Scope (S): UNCHANGED
  • Confidentiality impact (C): LOW
  • Integrity impact (I): NONE
  • Availability impact (A): NONE
created 1 month, 4 weeks ago Activity log
  • Created suggestion
Weblate: Missing access control for the AddonViewSet API exposes all addon configurations

Weblate is a web based localization tool. Prior to version 5.16.1, the REST API's `AddonViewSet` (`weblate/api/views.py`, line 2831) uses `queryset = Addon.objects.all()` without overriding `get_queryset()` to scope results by user permissions. This allows any authenticated user (or anonymous users if `REQUIRE_LOGIN` is not set) to list and retrieve ALL addons across all projects and components via `GET /api/addons/` and `GET /api/addons/{id}/`. Version 5.16.1 fixes the issue.

Affected products

weblate
  • ==< 5.16.1

Matching in nixpkgs

pkgs.weblate

Web based translation tool with tight version control integration

Package maintainers

Permalink CVE-2026-27840
4.3 MEDIUM
  • CVSS version: 3.1
  • Attack vector (AV): NETWORK
  • Attack complexity (AC): LOW
  • Privileges required (PR): NONE
  • User interaction (UI): REQUIRED
  • Scope (S): UNCHANGED
  • Confidentiality impact (C): NONE
  • Integrity impact (I): LOW
  • Availability impact (A): NONE
created 1 month, 4 weeks ago Activity log
  • Created suggestion
ZITADEL's truncated opaque tokens are still valid

ZITADEL is an open source identity management platform. Starting in version 2.31.0 and prior to versions 3.4.7 and 4.11.0, opaque OIDC access tokens in the v2 format truncated to 80 characters are still considered valid. Zitadel uses a symmetric AES encryption for opaque tokens. The cleartext payload is a concatenation of a couple of identifiers, such as a token ID and user ID. Internally Zitadel has 2 different versions of token payloads. v1 tokens are no longer created, but are still verified as to not invalidate existing session after upgrade. The cleartext payload has a format of `<token_id>:<user_id>`. v2 tokens distinguished further where the `token_id` is of the format `v2_<oidc_session_id>-at_<access_token_id>`. V1 token authZ/N session data is retrieved from the database using the (simple) `token_id` value and `user_id` value. The `user_id` (called `subject` in some parts of our code) was used as being the trusted user ID. V2 token authZ/N session data is retrieved from the database using the `oidc_session_id` and `access_token_id` and in this case the `user_id` from the token is ignored and taken from the session data in the database. By truncating the token to 80 chars, the user_id is now missing from the cleartext of the v2 token. The back-end still accepts this for above reasons. This issue is not considered exploitable, but may look awkward when reproduced. The patch in versions 4.11.0 and 3.4.7 resolves the issue by verifying the `user_id` from the token against the session data from the database. No known workarounds are available.

Affected products

zitadel
  • ==>= 2.31.0, <= 2.71.19
  • ==>= 4.0.0, < 4.11.0
  • ==>= 3.0.0, < 3.4.7

Matching in nixpkgs

Package maintainers

created 1 month, 4 weeks ago Activity log
  • Created suggestion
Discourse doesn't prevent moderators from exporting user Chat DMs

Discourse is an open source discussion platform. Prior to versions 2025.12.2, 2026.1.1, and 2026.2.0, moderators could export user Chat DMs via the CSV export endpoint by exploiting an overly permissive allowlist in `can_export_entity?`. The method allowed moderators to export any entity not explicitly blocked instead of restricting to an explicit allowlist. Versions 2025.12.2, 2026.1.1, and 2026.2.0 patch the issue. No known workarounds are available.

Affected products

discourse
  • ==< 2025.12.2
  • ==>= 2026.1.0-latest, < 2026.1.1
  • ==>= 2026.2.0-latest, < 2026.2.0

Matching in nixpkgs

Package maintainers

created 1 month, 4 weeks ago Activity log
  • Created suggestion
Discourse doesn't validate destination topic when moving posts

Discourse is an open source discussion platform. Prior to versions 2025.12.2, 2026.1.1, and 2026.2.0, the `move_posts` action only checked `can_move_posts?` on the source topic but never validated write permissions on the destination topic. This allowed TL4 users and category group moderators to move posts into topics in categories where they lack posting privileges (e.g., read-only categories or categories with group-restricted write access). Versions 2025.12.2, 2026.1.1, and 2026.2.0 patch the issue. No known workarounds are available.

Affected products

discourse
  • ==< 2025.12.2
  • ==>= 2026.1.0-latest, < 2026.1.1
  • ==>= 2026.2.0-latest, < 2026.2.0

Matching in nixpkgs

Package maintainers

Permalink CVE-2026-28296
4.3 MEDIUM
  • CVSS version: 3.1
  • Attack vector (AV): NETWORK
  • Attack complexity (AC): LOW
  • Privileges required (PR): NONE
  • User interaction (UI): REQUIRED
  • Scope (S): UNCHANGED
  • Confidentiality impact (C): LOW
  • Integrity impact (I): NONE
  • Availability impact (A): NONE
created 1 month, 4 weeks ago Activity log
  • Created suggestion
Gvfs: ftp gvfs backend: arbitrary ftp command injection via crlf sequences in file paths

A flaw was found in the FTP GVfs backend. A remote attacker could exploit this input validation vulnerability by supplying specially crafted file paths containing carriage return and line feed (CRLF) sequences. These unsanitized sequences allow the attacker to terminate intended FTP commands and inject arbitrary FTP commands, potentially leading to arbitrary code execution or other severe impacts.

References

Affected products

gvfs

Matching in nixpkgs

Package maintainers

Permalink CVE-2026-26077
6.5 MEDIUM
  • CVSS version: 3.1
  • Attack vector (AV): NETWORK
  • Attack complexity (AC): LOW
  • Privileges required (PR): NONE
  • User interaction (UI): NONE
  • Scope (S): UNCHANGED
  • Confidentiality impact (C): NONE
  • Integrity impact (I): LOW
  • Availability impact (A): LOW
created 1 month, 4 weeks ago Activity log
  • Created suggestion
Discourse doesn't ensure webhooks require a token

Discourse is an open source discussion platform. Prior to versions 2025.12.2, 2026.1.1, and 2026.2.0, several webhook endpoints (SendGrid, Mailjet, Mandrill, Postmark, SparkPost) in the `WebhooksController` accepted requests without a valid authentication token when no token was configured. This allowed unauthenticated attackers to forge webhook payloads and artificially inflate user bounce scores, potentially causing legitimate user emails to be disabled. The Mailpace endpoint had no token validation at all. Starting in versions 2025.12.2, 2026.1.1, and 2026.2.0, all webhook endpoints reject requests with a 406 response when no authentication token is configured. As a workaround, ensure that webhook authentication tokens are configured for all email provider integrations in site settings (e.g., `sendgrid_verification_key`, `mailjet_webhook_token`, `postmark_webhook_token`, `sparkpost_webhook_token`). There's no current workaround for mailpace before getting this fix.

Affected products

discourse
  • ==< 2025.12.2
  • ==>= 2026.1.0-latest, < 2026.1.1
  • ==>= 2026.2.0-latest, < 2026.2.0

Matching in nixpkgs

Package maintainers

created 1 month, 4 weeks ago Activity log
  • Created suggestion
Fleet: Authorization Bypass in certificate template batch deletion for team administrators

Fleet is open source device management software. In versions prior to 4.80.1, a broken authorization check in Fleet’s certificate template deletion API could allow a team administrator to delete certificate templates belonging to other teams within the same Fleet instance. Fleet supports certificate templates that are scoped to individual teams. In affected versions, the batch deletion endpoint validated authorization using a user-supplied team identifier but did not verify that the certificate template IDs being deleted actually belonged to that team. As a result, a team administrator could delete certificate templates associated with other teams, potentially disrupting certificate-based workflows such as device enrollment, Wi-Fi authentication, VPN access, or other certificate-dependent configurations for the affected teams. This issue does not allow privilege escalation, access to sensitive data, or compromise of Fleet’s control plane. Impact is limited to integrity and availability of certificate templates across teams. Version 4.80.1 patches the issue. If an immediate upgrade is not possible, administrators should restrict access to certificate template management to trusted users and avoid delegating team administrator permissions where not strictly required.

Affected products

fleet
  • ==< 4.80.1

Matching in nixpkgs

Package maintainers

created 1 month, 4 weeks ago Activity log
  • Created suggestion
Privilege Escalation via Mass Assignment Allows Regular Users to Set Topics as Global Banners

Discourse is an open source discussion platform. Prior to versions 2025.12.2, 2026.1.1, and 2026.2.0, an improper authorization check in the topic management logic allows authenticated users to modify privileged attributes of their topics. By manipulating specific parameters in a PUT or POST request, a regular user can elevate a topic’s status to a site-wide notice or banner, bypassing intended administrative restrictions. Versions 2025.12.2, 2026.1.1, and 2026.2.0 patch the issue. There are no practical workarounds to prevent this behavior other than applying the security patch. Administrators concerned about unauthorized promotions should audit recent changes to site banners and global notices until the fix is deployed.

Affected products

discourse
  • ==< 2025.12.2
  • ==>= 2026.1.0-latest, < 2026.1.1
  • ==>= 2026.2.0-latest, < 2026.2.0

Matching in nixpkgs

Package maintainers