Logging on Lessons learned

A format string in a TRACE logger can read the process environment

Tue, 06 Oct 2026 00:00:00 +0000

A TRACE handler that echoes a request with snprintf(response, size, request_line) does more than log attacker-controlled text. It turns the request line into a printf format string and can leak stack data in an authorized test, including pointers into argv and envp, through positional %p and %s conversions. The one-line fix is snprintf(response, size, "%s", request_line).

This is CWE-134, use of an externally controlled format string . The bug often hides in diagnostics because developers treat the third argument as plain text. For the printf family, it is the format string: a small program that says what to read and, with %n, where to write.

A bounded copy does not make the format safe

The length argument to snprintf bounds the output buffer. It does not stop format directives from being evaluated:

/* Vulnerable: request_line controls the format language. */
int len = snprintf(response, sizeof response, request_line);

/* Fixed: request_line is data for a constant format. */
int len = snprintf(response, sizeof response, "%s", request_line);

The same rule applies to printf(input), fprintf(log, input), and wrappers around them. When no formatting is needed, prefer fputs.

A small local regression fixture makes the difference visible without reading sensitive memory. Save this as format-log.c in a disposable directory:

#include <stdio.h>
#include <string.h>

static void render(char *out, size_t size, const char *input, int fixed) {
 if (fixed)
 snprintf(out, size, "%s", input);
 else
 snprintf(out, size, input);
}

int main(void) {
 char vulnerable[128], fixed[128];
 const char *probe = "TRACE /%p HTTP/1.1";
 render(vulnerable, sizeof vulnerable, probe, 0);
 render(fixed, sizeof fixed, probe, 1);
 printf("vulnerable=%s\nfixed=%s\n", vulnerable, fixed);
 return strcmp(fixed, probe) != 0 || strcmp(vulnerable, probe) == 0;
}

Run it locally:

cc -O0 -Wall -Wextra format-log.c -o format-log
./format-log

The vulnerable line expands %p; the fixed line preserves it literally. The pointer value is intentionally unspecified.

How to exercise the disclosure safely

On an authorized disposable target, start with a normal request and a literal-percent control. Then use %p or positional %N$p to map candidate argument slots. Dereferencing a candidate with %N$s asks the process to treat that value as a string pointer, so expect child crashes and test one slot per fresh connection. Never run a broad %s sweep against production.

Environment strings commonly sit near the initial argument and environment vectors. A pointer leak can therefore become a secret leak when a service receives credentials through environment variables. Slot numbers are build- and runtime-specific; a number from one binary is not a portable exploit.

Fork-per-connection servers make repeated probing easier than expected. Children inherit the parent’s already-randomized mappings so that addresses can remain stable across child connections until the parent restarts. ASLR still applies to the parent; fork() simply copies that layout.

Treat %n as a separate, higher-risk write primitive. A read-only demonstration is enough to prove the logging flaw and should be the limit of most authorized validation.

Fix the sink and reduce the impact

Make every format string a constant and enable compiler diagnostics such as -Wformat=2 -Wformat-security. Add a regression request containing %p, %s, and %n as literal text, then assert that the logger preserves every byte. Static analysis should flag tainted data reaching any printf-family format parameter.

Do not rely on input filtering. Blocking a few percent directives is easy to get wrong and leaves other format sinks exposed. Fix the call boundary.

Finally, keep long-lived credentials out of network-facing process environments where possible. Use narrowly scoped, short-lived credentials and isolate the component. That limits the damage from any memory disclosure, but it does not replace fixing the format string.

Search your diagnostic and TRACE paths for nonliteral printf formats before assuming they are harmless logging code.

QtInfoMsg is numerically above QtFatalMsg, so an INFO filter dropped every warning

Wed, 23 Sep 2026 16:00:00 +0200

A desktop app’s log file had about 20,000 lines in it, all of them INFO. There wasn’t a single WARN or ERROR line, even though the app had plenty of qWarning() and qCritical() calls. This was the filter in the custom message handler (trimmed):

void Logger::logMessage(QtMsgType msgType, const QMessageLogContext &context, const QString &message)
{
 if (msgType < minimumType && minimumType != QtFatalMsg && !message.startsWith("##")) {
 return; // below the configured level
 }
 ...
}

It assumes QtMsgType is ordered by severity. It isn’t:

enum QtMsgType {
 QtDebugMsg, // 0
 QtWarningMsg, // 1
 QtCriticalMsg, // 2
 QtFatalMsg, // 3
 QtInfoMsg, // 4, added in Qt 5.5
 QtSystemMsg = QtCriticalMsg
};

At INFO, minimumType is QtInfoMsg (4). Warning (1) and critical (2) are both below 4, so they were thrown away. Info lines got through, so the log looked healthy.

If your Qt message handler compares QtMsgType values with < or >, it has this bug.

How it got there

No single commit introduced this:

Before Qt 5.5 the enum was in severity order, so msgType < minimumType was correct when the handler was written.
Qt 5.5 added QtInfoMsg at the end, to keep the existing values stable. The app also added INFO to the end of its own level enum, and nobody looked at the comparison again.
Years later, a one-line change moved the fallback level from WARN to INFO. At WARN, the bug had only cost info lines. At INFO it cost warnings and errors, and since INFO was now the default, that became the normal behavior.

Each step looked harmless in its own diff. The cause only showed up when the history was read in order.

Red tests first

Each test sets a level, sends one probe per message type through the real handler to a real log file, and records which probes ended up in the file:

// One letter per probe that reached the file: d(ebug), i(nfo), w(arning), c(ritical)
QString writtenAt(Logger::LogLevel level) {
 log->setLogLevel(level);
 qDebug("probe d");
 qInfo("probe i");
 qWarning("probe w");
 qCritical("probe c");
 const QString content { logContent() };
 QString written;
 for (const QChar probe : QStringLiteral("diwc")) {
 if (content.contains(QStringLiteral("probe ") + probe)) written += probe;
 }
 return written;
}

TEST_F(LoggerTest, logMessage_InfoLevel_WarningWritten) {
 ASSERT_EQ(writtenAt(Logger::LogLevel::INFO), "iwc");
}

Against the old handler, five of the twelve logger tests failed:

Level	Expected	Written
INFO	`iwc`	`i`
WARN	`wc`	`iwc`
ERROR	`c`	`ic`
FATAL	(none)	`diwc`

The two bottom rows are separate bugs. Info (4) is above every other type, so it got through at WARN and ERROR. The minimumType != QtFatalMsg exemption meant FATAL wrote everything.

The fifth failure was a different bug: a level saved as ERROR came back as INFO after a restart. The app’s enum key was Error (an all-caps ERROR collides with a Windows macro), the setting was stored as ERROR, and QMetaEnum::keyToValue is case-sensitive. The lookup failed, so it fell back to the default.

Fix

Map the message types to severity explicitly, and compare those numbers instead:

// Qt numbers its message types in the order they were added, info last, not by severity
int severity(QtMsgType msgType) {
 switch (msgType) {
 case QtDebugMsg: return 0;
 case QtInfoMsg: return 1;
 case QtWarningMsg: return 2;
 case QtCriticalMsg: return 3;
 case QtFatalMsg: return 4;
 }
 return 4;
}

if (severity(msgType) < severity(minimumType) && !message.startsWith("##")) {
 return;
}

The FATAL exemption is gone. Each level now means “this severity and above.” If a future Qt version adds a type, the switch with no default makes the compiler warn about it, and the fallback treats the unknown type as most severe, so it gets logged rather than dropped.

The stored level is now matched without regard to case:

for (int i = 0; i < metaEnum.keyCount(); ++i) {
 if (stored.compare(metaEnum.key(i), Qt::CaseInsensitive) == 0) return LogLevel(metaEnum.value(i));
}
return LogLevel::INFO;

The same twelve tests passed after the fix, and so did the full suite.

The rollout catch

Fixing a filter that has silently dropped messages turns on log statements that nobody has read in years. Here, some of those warnings included user file names. The fix couldn’t ship until we moved those down to DEBUG. Before you fix a filter like this, grep for every qWarning and qCritical call it was dropping, because those are the lines your users will start sending you.

Takeaway

QtMsgType values are not ordered by severity. Never compare them with < or >. Map them first.
A log full of INFO lines with no warnings in it is suspicious, not reassuring.
Test the filter through the real handler with one probe per type, one test per level. The four-letter strings make the whole matrix fit on one screen.
Check enum-to-string round trips (QMetaEnum::keyToValue) with an actual save and reload, not just a set and get.