Format String in Adonisjs with Mutual Tls

Format string vulnerabilities occur when user-controlled input is passed directly to functions like printf-style formatting routines without proper sanitization, allowing an attacker to read from or write to memory. In AdonisJS, which is built on Node.js, the most common scenario is unsafe usage of console.log, util.format, or third-party logging libraries where a format string is dynamically constructed from request data.

Mutual TLS (mTLS) adds a strong client authentication layer, but it does not inherently protect against application-level logic flaws such as format string bugs. When mTLS is in use, the server may trust the identity of the client certificate and proceed to process incoming data with higher privileges or broader trust. If the application subsequently uses certificate metadata (e.g., subject distinguished name, serial number, or common name) in a formatted string without validation, an attacker who presents a valid but malicious certificate can supply format specifiers via crafted fields.

For example, an AdonisJS route that logs certificate details could become an injection sink:

// Unsafe: using certificate fields directly in a format string
const { cert } = request.auth
const message = format('Peer DN: %s, serial: %d', cert.subject, cert.serialNumber)
logger.info(message) // Risk: %s, %d, or %n from attacker-controlled cert fields

An attacker providing %n in the distinguished name can potentially write to memory, leading to information disclosure or code execution. Even when using console.log('%s', userInput), a malicious payload like %s%s%s%s can cause excessive memory consumption or expose adjacent stack contents in some runtime configurations.

In the context of an mTLS-enabled AdonisJS service, the interaction becomes more dangerous because the server may assume that authenticated connections are safe and skip additional sanitization. This trust boundary mismatch means format string issues are more likely to be reachable and more impactful, as the server might process attacker-controlled certificate fields alongside internal business logic.

Additionally, format string bugs can be chained with other findings such as Input Validation or Data Exposure. For instance, unchecked request parameters combined with mTLS-authenticated sessions may allow an attacker to leak sensitive application state through formatted error messages or logs, which are then indexed or surfaced in the Dashboard or via CLI/JSON report outputs.

Remediation focuses on never trusting certificate-derived data and using safe formatting practices. Treat fields like subject DN, issuer, and serial number as untrusted input, and avoid passing them directly to format string functions.

1) Use parameterized logging instead of dynamic format strings. For structured logging, prefer key-value pairs:

// Safe: structured logging without format string interpolation
const { cert } = request.auth
logger.info({ subject: cert.subject, serial: cert.serialNumber }, 'peer_cert') // No format string

2) If you must produce a human-readable message, use concatenation or template literals, and sanitize each component:

// Safe: explicit concatenation with sanitized values
const safeSubject = String(cert.subject || '').replace(/[%\n\r]/g, '_')
const safeSerial = Number.isInteger(cert.serialNumber) ? cert.serialNumber : 0
const message = `Peer DN: ${safeSubject}, serial: ${safeSerial}`
console.log(message)

3) Validate and restrict certificate fields before use. Enforce strict patterns for expected values and reject unexpected characters:

// Safe: validate certificate fields before processing
const { cert } = request.auth
const dnPattern = /^[A-Za-z0-9_\-\/=+ ,]+$/ // basic safe character set
if (!dnPattern.test(cert.subject)) {
  throw new Error('Invalid certificate subject')
}
// Proceed with safe usage

4) Configure AdonisJS logger transport options to avoid exposing raw format strings in output, and ensure any third-party logging plugins are reviewed for format string handling.

5) Combine mTLS with other security checks. Use the middleBrick CLI to scan your endpoint and verify that no format string issues remain in routes that rely on mTLS authentication:

# Scan from terminal with middlebrick
middlebrick scan https://api.example.com

These steps ensure that even with mutual TLS providing strong client authentication, your application code does not introduce format string vulnerabilities via certificate-derived data.