Problem
Several exception messages in the WordPress integration (and the shared db/datastore layers) interpolate database internals into the message string:
CanQueryWordPressDatabase / QueryStrategy: throw new DatastoreErrorException('... - ' . $wpdb->last_error) and '... query: ' . $query — raw MySQL error text and assembled SQL.RecordNotFoundException('No records found for query: ' . $query) (and No value/No record siblings).
When such an exception is uncaught it can reach output (PHP fatal with display_errors/WP_DEBUG_DISPLAY), and when caught into a REST error response the SQL/DB error lands in the JSON message field. Either way this is information disclosure — it leaks query structure and DB error detail to the client. (It is also what triggers WordPress's WordPress.Security.EscapeOutput.ExceptionNotEscaped sniff in consumers, though HTML-escaping is the wrong remedy for a JSON/log sink.)
Desired outcome
Exception messages should not carry SQL strings or $wpdb->last_error to the caller. Log the query/DB error at the point of failure (via the framework logger) and throw a stable, non-leaking message. Internal identifiers (class/param/field names) in other messages are fine.
Notes
Surfaced by the Siren WordPress plugin during WordPress.org review-simulation.
Problem
Several exception messages in the WordPress integration (and the shared db/datastore layers) interpolate database internals into the message string:
CanQueryWordPressDatabase/QueryStrategy:throw new DatastoreErrorException('... - ' . $wpdb->last_error)and'... query: ' . $query— raw MySQL error text and assembled SQL.RecordNotFoundException('No records found for query: ' . $query)(andNo value/No recordsiblings).When such an exception is uncaught it can reach output (PHP fatal with
display_errors/WP_DEBUG_DISPLAY), and when caught into a REST error response the SQL/DB error lands in the JSONmessagefield. Either way this is information disclosure — it leaks query structure and DB error detail to the client. (It is also what triggers WordPress'sWordPress.Security.EscapeOutput.ExceptionNotEscapedsniff in consumers, though HTML-escaping is the wrong remedy for a JSON/log sink.)Desired outcome
Exception messages should not carry SQL strings or
$wpdb->last_errorto the caller. Log the query/DB error at the point of failure (via the framework logger) and throw a stable, non-leaking message. Internal identifiers (class/param/field names) in other messages are fine.Notes
Surfaced by the Siren WordPress plugin during WordPress.org review-simulation.