Ghost's public content API allows unauthenticated extraction of author email addresses and bcrypt password hashes. This discovery covers two variants: the original bypass through the authors endpoint, and a bypass of Ghost's initial fix through the posts and pages endpoints.
The /ghost/api/content/authors/ endpoint accepts a filter query parameter. The rejectPrivateFieldsTransformer function in ghost/core/core/server/api/endpoints/authors-public.js rejects filter keys that start with password or email, but the underlying NQL query builder also accepts table-qualified column references. Prefixing a private field with users. bypasses the restriction entirely, as users.password does not start with password:
GET /ghost/api/content/authors/?key=CONTENT_API_KEY&filter=users.password:>='$2a' HTTP/1.1
Host: targetGhost's fix for the first variant reworked the rejection into the NQL convertor, checking the last segment of a dot-separated filter key via .split('.').pop(). However, the processStatement function in mongo-knex/lib/convertor.js destructures the key as [tableName, columnName], taking only the first two segments. A three-segment key like authors.password.x defeats the check: the transformer inspects only the last segment, x, which does not match any private field name, while the query builder uses authors as the table name and password as the column name (ignoring the third segment).
This variant works through the posts and pages API endpoints rather than the authors API:
GET /ghost/api/content/posts/?key=CONTENT_API_KEY&filter=authors.password.x:>='$2a' HTTP/1.1
Host: targetBoth variants are exploited the same way. By performing boolean-based binary search over the filter parameter, iterating over candidate characters with >= comparisons, an unauthenticated attacker extracts the full email address and bcrypt password hash for every author user.
In SQLite environments, the full bcrypt hash is extracted with exact case and can be cracked offline to gain administrator access. In MySQL environments, the default case-insensitive collation means only a lowercase form of the hash is recoverable, which is an order of magnitude more expensive to brute force, so only email addresses are likely exposed.
This vulnerability was responsibly disclosed and has been patched by the vendor.