IT-Sicherheit - bleiben Sie auf dem Laufenden
Täglich werden neue Schwachstellen, Angriffs-Vektoren, Cyber-Attaken und Fehler in Software, Netzwerken und Infrastrukturen bekannt - teilweise betreffen diese nur bestimmte Softwarelösungen oder spezifische Szenarien, manchmal betreffen Sie jedoch auch ganze Industriezweige, weit verbreitete Arbeitsweisen und grundlegende Technologien wie bei Heartbleed (SSL) oder Log4Shell (Protokollierung). Ergreifen Sie Maßnahmen, um Ihre Infrastruktur und Daten sicher zu halten.
Gemeinsam erfassen wir, welche Komponten und Abhängigkeiten Sie einsetzen und überwachen die CVE und viele weitere Quellen um im Falle von Mängeln oder Angriffspunkten schnell handeln zu können.
Wir simulieren Angriffe und Testen Ihre Anwendungen, Webseiten, die Infrastruktur und Prozesse auf mögliche Sicherheitslücken, Mängel und Angriffsvektoren um Risiken fürhzeitig zu erknennen und Lücken zu schließen.
Wir implementieren aktiv Monitore und überwachen somit Anfragen um frühzeitig Angriffe und verdächtige Aktivitäten zu identifizieren. Verdächte Aktivitäten können zur Alarmierung oder zu automatischen Sperrungen und Ausschlüssen führen, um einen hohen Standard zu gewährleisten.
Den Bedrohungen der IT-Welt sind Sie nicht schutzlos ausgeliefert - es ist jedoch wichtig dem Thema IT-Sicherheit Aufmerksamkeit zu schenken, um einen verantwortungsbewussten und rechtskonformen Umgang mit Unternehmens- und Kundendaten zu gewährleisten.
| Risiko / Label | Veröffentlichung | |
|---|---|---|
| Risiko 9.8 / 10 CVE-2025-1889 | gerade eben | |
| picklescan before 0.0.22 only considers standard pickle file extensions in the scope for its vulnerability scan. An attacker could craft a malicious model that uses Pickle and include a malicious pickle file with a non-standard file extension. Because the malicious pickle file inclusion is not considered as part of the scope of picklescan, the file would pass security checks and appear to be safe, when it could instead prove to be problematic. | ||
| Risiko 9.8 / 10 CVE-2024-8309 | gerade eben | |
| A vulnerability in the GraphCypherQAChain class of langchain-ai/langchain-community version 0.2.5 allows for SQL injection through prompt injection. This vulnerability can lead to unauthorized data manipulation, data exfiltration, denial of service (DoS) by deleting all data, breaches in multi-tenant security environments, and data integrity issues. Attackers can create, update, or delete nodes and relationships without proper authorization, extract sensitive data, disrupt services, access data across different tenants, and compromise the integrity of the database. | ||
| Risiko 2 / 10 CVE-2026-73425 | vor 1 Stunde(n) | |
| ## Summary The `@astrojs/netlify` adapter converts each `image.remotePatterns` entry into a regular expression that is written to `.netlify/v1/config.json` under `images.remote_images`. Netlify's Image CDN uses these regexes as the allowlist that decides which remote image URLs it will optimize. `remotePatternToRegex()` escapes `.` in the hostname but interpolates the literal `pathname` into the regex **without escaping regex metacharacters**. As a result, the generated allowlist is broader than the pattern the developer declared, and broader than Astro's canonical `matchPattern()` helper (which compares non-wildcard pathnames by exact string equality). This is a residual of the same bug class addressed in CVE-2026-54300 (PR #17018, commit `1310277d`). That fix corrected wildcard semantics and added a `$` anchor but did not add metacharacter escaping for literal pathnames. ## Details In `packages/integrations/netlify/src/index.ts`, `remotePatternToRegex()` escapes dots in the hostname: ```js regexStr += hostname.replace(/\./g, '\\.'); ``` but interpolates the pathname unescaped in all three branches, e.g. the exact-match branch: ```js regexStr += `(\\${pathname})`; ``` Any regex metacharacter in the literal path (`.`, `+`, `?`, `(`, `[`, ...) is therefore passed through raw. Because `.` matches any character (including `/`), a restrictive pattern is silently widened. The security boundary on Netlify is the generated regex itself — Netlify's Image CDN enforces it directly and Astro's runtime `matchPattern()` is not in the loop for this path, so there is no compensating layer that re-validates the request. ## Proof of Concept Configure an SSR site with a literal pathname containing a `.`: ```js // astro.config.mjs image: { remotePatterns: [{ protocol: 'https', hostname: 'cdn.example.com', pathname: '/img/v1.0/file', }], } ``` Run `astro build` and inspect `.netlify/v1/config.json` `images.remote_images[0]`: ``` https://cdn\.example\.com(:[0-9]+)?(\/img/v1.0/file)([?][^#]*)?$ ``` Testing the generated regex: - `https://cdn.example.com/img/v1.0/file` -> MATCH (intended) - `https://cdn.example.com/img/v1X0/file` -> MATCH (bypass; the unescaped `.` matches any character) - `https://cdn.example.com/img/v1/0/file` -> MATCH (bypass; `.` also matches `/`, crossing a path segment) Astro's canonical `matchPattern()` (exact string equality on the pathname) rejects both bypass URLs. ## Impact Netlify's Image CDN accepts optimization requests for URLs on the allowed host that the developer's `remotePatterns` entry was intended to exclude. The hostname remains correctly anchored, so the broadening is confined to the pathname dimension on an already-allowed host. Realistic impact depends on whether other images the developer meant to keep out of their CDN exist at metacharacter-adjacent paths on that host. This affects reasonable, non-permissive configurations, since any `pathname` containing a `.` (file extensions, version segments) is affected. ## Patches A fix will escape all regex metacharacters in the literal portions of each `remotePatterns` component before interpolation, applying only Astro's documented wildcard semantics explicitly. A regression corpus validates the generated Netlify regexes against `@astrojs/internal-helpers`' `matchPattern()`. ## Workarounds Avoid regex metacharacters (notably `.`) in `image.remotePatterns[].pathname` values, or scope the allowed host so that unintended paths are not reachable. ## Credit Reported by @sec-reex as part of an incomplete-patch measurement study (responsible disclosure). | ||
| Risiko 5 / 10 CVE-2026-73423 | vor 1 Stunde(n) | |
| ## Summary In the composable `astro/hono` pipeline, the `security.checkOrigin` protection is only installed by the `middleware()` primitive. The `actions()` and `pages()` primitives each dispatch to user code independently, so a pipeline that mounts either primitive before (or without) `middleware()` will bypass the origin check for those requests. ## Details `security.checkOrigin` (default: `true`) is intended to reject cross-site `POST`/`PUT`/`PATCH`/`DELETE` form submissions. In the classic pipeline (`astro()` all-in-one), the check always runs because Astro injects a virtual middleware module even when the user has no `src/middleware.ts`. In the composable `astro/hono` pipeline, the user assembles primitives manually. The check is only installed inside `middleware()` — so: - Mounting `actions()` before `middleware()` allows cross-origin form-encoded action requests to execute before the gate runs. The `examples/advanced-routing` example and the Cloudflare `hono` docs shipped this order. - Omitting `middleware()` entirely (reasonable for apps with no custom middleware) silently drops `checkOrigin` protection for all on-demand endpoints and pages dispatched through `pages()`. The attack is a blind write-only CSRF: the attacker can trigger a state-mutating action or endpoint handler using the victim's cookies, but cannot read the cross-origin response body. ## Affected versions Astro `>= 7.0.0` when using the composable `astro/hono` pipeline with either: - `actions()` mounted before `middleware()`, or - `pages()` used without `middleware()` The default (non-composable) pipeline is not affected. ## Fix The origin check is now applied at each dispatch sink (`ActionHandler.handle` and `PagesHandler.handleWithErrorFallback`), gated on `manifest.checkOrigin`, using the same predicate as the middleware. The check is order-independent and a no-op when `middleware()` has already run. Fix: https://github.com/withastro/astro/pull/17250 ## Workaround Ensure `middleware()` is mounted before both `actions()` and `pages()` in the composable pipeline, and that it is always included even when no custom middleware logic is needed: ```ts app.use(middleware()); app.use(actions()); app.use(pages()); ``` | ||
| Risiko 5 / 10 CVE-2026-73422 | vor 1 Stunde(n) | |
| ## Summary
Astro's server-side View Transition CSS generator interpolates animation properties into an inline `` sequence, terminate the generated style element, and inject arbitrary HTML or JavaScript.
This is similar to GHSA-8hv8-536x-4wqp, but exploits a different injection point: unescaped View Transition animation values in a server-generated ``));
```
Animation properties are added to the stylesheet without escaping:
```ts
if (anim.duration) {
addAnimationProperty(builder, 'animation-duration', toTimeValue(anim.duration));
}
```
For string values, `toTimeValue()` returns the input unchanged:
```ts
export function toTimeValue(num: number | string) {
return typeof num === 'number' ? num + 'ms' : num;
}
```
As a result, a `duration` value containing `` can escape from the generated style element.
Other `TransitionAnimation` properties, including `easing`, `direction`, `delay`, `fillMode`, and `name`, are serialized by the same animation builder. The following PoC only relies on the official `fade()` helper and its `duration` option.
## PoC
Using:
- `astro@7.0.9`
- `@astrojs/node@11.0.2`
### `astro.config.mjs`
```js
import node from '@astrojs/node';
import { defineConfig } from 'astro/config';
export default defineConfig({
output: 'server',
adapter: node({ mode: 'standalone' }),
});
```
### `src/pages/index.astro`
```astro
---
import { fade } from 'astro:transitions';
const duration = Astro.url.searchParams.get('duration') ?? '300ms';
---
Animated content
```
### Payload:
open:
```text
http://localhost:4321/?duration=%3C%2Fstyle%3E%3Cscript%3Ealert(1)%3C%2Fscript%3E%3C!--
```
The browser interprets `` as the end of the generated style element and executes the injected script. An alert dialog is displayed when the page is opened.
|
||
| Risiko 9.5 / 10 CVE-2026-73421 | vor 1 Stunde(n) | |
| ### Impact `next-auth` (Auth.js) v5 applications that gate access by checking only for the **existence** of the `auth` object — the pattern shown in the official [session management / protecting resources guide](https://authjs.dev/getting-started/session-management/protecting) — are affected. When the Auth.js configuration produces a server-side error, the `auth` object exposed by the `auth()` wrapper (in middleware, Route Handlers, etc.) is **populated with an error object instead of being `null`**: ```json { "message": "There was a problem with the server configuration. Check the server logs for more information." } ``` Because this object is truthy, any authorization check of the form `!!auth` (or `if (req.auth)`) evaluates to `true` for **every** request, including unauthenticated ones. The application *fails open*: instead of denying access when the auth layer is broken, it grants access to everyone. ```ts // middleware.ts — affected pattern export default auth((req) => { const { nextUrl, auth } = req const isLoggedIn = !!auth // <-- always true when the configuration is broken // ... }) ``` A representative trigger is a provider that is missing required configuration. For example, a Keycloak provider with neither `issuer` nor `authorization` endpoint set logs: ``` [auth][error] InvalidEndpoints: Provider "keycloak" is missing both `issuer` and `authorization` endpoint config. At least one of them is required. ``` …and from that point on `auth` is the error object above, so `!!auth` is permanently `true`. The same fail-open behavior occurs for other server-configuration errors (for example, an unset `AUTH_SECRET`). There is **no impact while the configuration is valid**. The risk materializes when a previously-working deployment becomes misconfigured — e.g. an environment variable is changed or removed during a deploy — at which point existence-based auth checks silently stop protecting routes and all visitors are treated as authenticated. Because the failure mode is silent and grants access to everyone, the consequences can be severe. This is an instance of CWE-636 (Not Failing Securely / "Failing Open") leading to improper authorization (CWE-285). ### Patches The fix ensures that a server-configuration error no longer surfaces as a truthy `auth` object: existence checks fail **closed** rather than open. This is released in `next-auth@`. To upgrade: ```sh npm i next-auth@beta ``` ```sh yarn add next-auth@beta ``` ```sh pnpm add next-auth@beta ``` ### Workarounds If you cannot upgrade immediately, check for a concrete user/session property rather than the bare object, so a configuration-error object is not treated as an authenticated session: ```ts // middleware.ts export default auth((req) => { // `auth.user` is only present on a real session; resilient to config-error objects const isLoggedIn = !!req.auth?.user // ... }) ``` As defense in depth, make Auth.js configuration errors fail loudly in your deployment pipeline (for example, treat `[auth][error]` log lines as a failed health check) so a broken configuration cannot silently reach production. As always, an existing session indicates authentication only — for authorization, perform an explicit role/permission check rather than relying on session existence. See the [role-based access control guide](https://authjs.dev/guides/role-based-access-control). ### References - Protecting resources / session management: https://authjs.dev/getting-started/session-management/protecting - Role-based access control (RBAC): https://authjs.dev/guides/role-based-access-control - Auth.js error reference: https://authjs.dev/reference/core/errors ### For more information If you have any concerns, Auth.js requests responsible disclosure, outlined here: https://authjs.dev/security ### Credits Reported by @marc-zollingkoffer-syzygy. | ||
| Risiko 9.5 / 10 CVE-2026-73420 | vor 1 Stunde(n) | |
| ## Summary The default email-address normalizer used by the email/magic-link sign-in flow validates the address **before** applying Unicode normalization. An address can contain a Unicode character that is not an ASCII `@` (U+0040) but canonicalizes to one under NFKC/NFKD normalization (the normalization commonly applied by mail libraries and services for internationalized email). Such an address passes the normalizer's single-`@` check, but a downstream mail library that normalizes the string then sees two `@` separators and may deliver the passwordless sign-in link to a different recipient than intended. This is an instance of validating before canonicalizing. ## Am I affected? You may be affected if **all** of the following hold: - You use `next-auth` `>= 4.0.0, < 4.24.14`, or `@auth/core` `>= 0.1.0, < 0.41.3`. - You have the email / magic-link (passwordless) provider enabled. - You rely on the built-in default identifier normalizer (you have not supplied your own `normalizeIdentifier`). - Your `sendVerificationRequest` implementation uses a mail library or delivery service that applies Unicode normalization to recipient addresses (most internationalized-email/SMTPUTF8-capable senders do). You are **not** affected if you do not use the email provider, or if your normalizer/mailer rejects or canonicalizes non-ASCII addresses before they are validated. ## Impact - Account takeover: an attacker who knows a victim's email address can request a magic link that is delivered to an attacker-controlled mailbox, then use it to sign in as the victim. - No victim interaction is required to misroute the link; the attacker initiates the flow. ## Patched version The fix applies Unicode (NFKC) normalization before the address is validated, so homoglyph separators are collapsed and rejected up front. Upgrade to the first release containing this fix (pending; this advisory will be updated with the exact patched version before publication). No application code changes are required after upgrading. ## Workarounds If you cannot upgrade immediately: - Supply a custom `normalizeIdentifier` on the email provider that calls `identifier.normalize("NFKC")` (and lower-cases/trims) **before** any validation, and rejects addresses that do not contain exactly one `@` after normalization. - Or reject any address whose local part or domain contains non-ASCII characters, if your user base does not require internationalized email addresses. ## Credit Reported by @kakashi-kx. Thank you for the responsible disclosure. | ||
| Risiko 5 / 10 CVE-2026-73419 | vor 1 Stunde(n) | |
| ## Summary Auth.js stores the OAuth/OIDC anti-CSRF checks (`state`, `nonce`, and the PKCE verifier) in global cookies that are not bound to the provider that created them. On callback, a check value minted during a sign-in started with one provider can satisfy the callback for a different provider, because the stored cookie is not verified against the callback provider's identity (provider id, issuer, client id, or redirect URI). In a multi-provider app that allows account linking while logged in, this provider-confusion / mix-up condition can let an attacker link their account at a second provider to a victim's user. ## Am I affected? You may be affected if **all** of the following hold: - You use `next-auth` `<= 4.24.14` or `>= 5.0.0-beta.1, <= 5.0.0-beta.31`, or `@auth/core` `<= 0.41.2`. - You configure multiple OAuth/OIDC providers. - You allow users to link additional providers while logged in. - At least one configured provider's authorization request is observable by an attacker, and at least one target provider's callback can be satisfied without a PKCE verifier (i.e. it relies only on `state` or only on `nonce`). You are **not** affected if you use a single OAuth provider, do not allow logged-in account linking, or all providers enforce PKCE. ## Impact - Account-linking confusion: an attacker can get their account at a target provider linked to the victim's Auth.js user, granting the attacker persistent sign-in to the victim's account through that linked provider. - Exploitation requires luring the victim into starting a legitimate same-origin flow; it cannot be performed by cross-site request forgery alone, which reduces practical likelihood. ## Patched version The fix binds the OAuth check cookies to the provider/authorization flow that created them, so a callback cannot consume a check value minted for a different provider. Upgrade to the first releases containing this fix (pending; this advisory will be updated with exact patched versions before publication). ## Workarounds If you cannot upgrade immediately: - Enable PKCE (`checks: ["pkce"]`, in addition to `state`/`nonce`) on every provider that supports it; PKCE blocks the practical code-swap variant because the attacker cannot observe the relying party's verifier. - Avoid offering logged-in account linking across multiple providers where one provider is lower-trust or attacker-observable. - Treat `events.linkAccount` as sensitive: add audit logging, user notification, or out-of-band confirmation so that any unexpected link is visible (defense-in-depth, not a root-cause fix). ## Credit Reported by @Nadav0077. Thank you for the responsible disclosure. | ||
| Risiko 7.5 / 10 CVE-2026-73418 | vor 1 Stunde(n) | |
| ## Summary The exported `getToken()` helper (`next-auth/jwt` and `@auth/core/jwt`) can throw an uncaught exception when it reads a malformed `Authorization: Bearer …` header. When no session cookie is present, `getToken()` URL-decodes the bearer value before validating it, and malformed percent-encoding causes the decode step to throw rather than being treated as an invalid token. Because `getToken()` is commonly called in API routes, middleware, and other request handlers, a single unauthenticated request can trigger an unhandled exception in code paths that authenticate requests. ## Am I affected? You are affected if **all** of the following hold: - You use `next-auth` `<= 5.0.0-beta.25` (or `@auth/core` exposing the same `getToken()` implementation). - Your application calls `getToken()` directly — for example in a Route Handler, middleware, or server-side request handler. - You do not wrap that `getToken()` call in your own `try/catch`. You are **not** affected if you only use the framework's `auth()` helper and never call `getToken()` yourself, or if every `getToken()` call site already has its own exception handling. ## Impact - Denial of service: an unauthenticated request carrying a malformed Bearer authorization header can raise an unhandled exception in any handler that calls `getToken()`. - The impact is per-request and limited to availability; it does not expose tokens, sessions, or other data, and does not bypass authentication. CWE-20: Improper Input Validation. ## Patched version The fix makes `getToken()` treat a malformed Bearer value as an invalid token and return `null`, matching how other undecodable tokens are already handled. Upgrade to the first release containing this fix (to be published; this advisory will be updated with the exact patched version before publication) and no code changes are required. ## Workarounds If you cannot upgrade immediately, either: - **Config/code-level:** wrap your `getToken()` calls so a thrown error is treated as "no token", e.g. ```ts let token = null try { token = await getToken({ req, secret }) } catch { token = null } ``` - Or strip/normalize the incoming `Authorization` header at the edge (proxy, middleware) before it reaches `getToken()`, rejecting values whose Bearer portion is not valid percent-encoding. ## Credit Reported by @deprrous. Thank you for the responsible disclosure. | ||
| Risiko 2 / 10 CVE-2026-59730 | vor 16 Tag(en) | |
| ### Impact With `trailingSlash: 'always'` configured, the `@astrojs/node` standalone server's static file handler appends a trailing slash to request paths and issues a `301` redirect. Paths beginning with `/\` (slash-backslash) were not recognized as internal paths, so the handler would echo the raw path back in the `Location` header. Because browsers treat `\` as `/` per the WHATWG URL specification, the resulting redirect could resolve to an external host. **Preconditions:** - `trailingSlash: 'always'` must be set (non-default; the default is `'ignore'`) - The request path must not have a file extension in its final segment - An attacker must deliver the crafted link to a user ### Patches Fixed by treating backslash-prefixed paths the same as `//`-prefixed paths in `isInternalPath()`, so they are no longer rewritten with a trailing slash. ### Workarounds Use the default `trailingSlash: 'ignore'` setting, which does not issue trailing-slash redirects in the static file handler. ### References - [WHATWG URL spec: backslash normalization](https://url.spec.whatwg.org/#url-parsing) | ||
| Risiko 5 / 10 CVE-2026-59728 | vor 16 Tag(en) | |
| ## Summary
In `@astrojs/rss`, the `source.title` and `enclosure.type` item fields are interpolated directly into XML template strings without XML-character escaping before being parsed by `fast-xml-parser`. An attacker who controls these field values can inject arbitrary XML elements into the generated RSS feed.
## Details
Two fields in `packages/astro-rss/src/index.ts` are affected:
### `source.title`
```typescript
item.source = parser.parse(
` |
||
| Risiko 5 / 10 CVE-2026-59729 | vor 16 Tag(en) | |
| ## Summary
The fix for CVE-2026-54298 (GHSA-jrpj-wcv7-9fh9) added an `INVALID_ATTR_NAME_CHAR` guard to `addAttribute()` so that spread-prop attribute names containing `"' >/=` or whitespace are dropped. A second attribute-rendering path, `renderHTMLElement()` in `packages/astro/src/runtime/server/render/dom.ts`, has its own inline attribute loop that does not go through `addAttribute()` and was not updated. It interpolates the attribute name unescaped and only escapes the value, so untrusted prop keys spread onto a native-`HTMLElement`-subclass component can still break out of the attribute context, resulting in XSS.
## Details
`renderHTMLElement` builds attributes directly:
```js
for (const attr in props) {
attrHTML += ` ${attr}="${toAttributeString(await props[attr])}"`;
}
```
The attribute name (`attr`) is interpolated raw; only the value is escaped via `toAttributeString`. By contrast, the hardened `addAttribute` in `util.ts` rejects invalid names:
```js
if (INVALID_ATTR_NAME_CHAR.test(key)) { return ''; } // /[\s"'>/=]/
```
`renderHTMLElement` is reached from `component.ts` when the component is a native `HTMLElement` subclass:
```js
if (!renderer && typeof HTMLElement === 'function' && componentIsHTMLElement(Component)) {
const output = await renderHTMLElement(result, Component, _props, slots);
}
```
where `_props` carries spread props verbatim.
### Reachability
The branch only runs when `typeof HTMLElement === 'function'` at SSR time. In default Node SSR `HTMLElement` is `undefined`, so the branch is dead. It becomes reachable when the SSR runtime exposes a global `HTMLElement` (Deno, Bun with a DOM shim, or jsdom/happy-dom in Node) **and** a class extending `HTMLElement` is used directly as an Astro component that receives untrusted-keyed spread props.
## Proof of Concept
Given malicious spread props:
```js
const maliciousProps = {
'onmouseover=alert(document.domain) x': 'y',
'x>': 'z',
};
```
- `addAttribute` (post-fix) → ` | ||