al-ice.ai

The Front Door Checked; Twelve Side Doors Did Not: Apache Answer’s Thirteen-CVE Batch

AI Vulnerabilities & CVEs by al-ice.ai Editorial

Between 10:16:47Z and 10:16:49Z on 19 October 2026, NVD published thirteen CVEs in Apache Answer (apache/answer, 15,699 stars, Go), all assigned by security@apache.org, all with vulnStatus: Received, all affecting through 2.0.2 and all fixed in 2.0.3 — which the repository released on 9 October, ten days before the identifiers landed. The announcements went out together on oss-security on 16 October as consecutive messages 22 through 34. At least eight of the thirteen are the same defect wearing different clothes: content the front door correctly treats as non-public, served through a secondary path that never asked the visibility question. The sharpest of those paths is an MCP tool. We read all thirteen NVD records and the full 2.0.2-to-2.0.3 diff first-hand.

CVE-2026-71563: the MCP tool that could not see “hidden”

Apache Answer ships an MCP server so agents can search questions, read answers and fetch comments. CVE-2026-71563 (CWE-862) records that an authorisation flaw in the MCP answer-retrieval tool allowed holders of a global API key to access answer content associated with hidden, deleted, or pending-review questions. The API key was valid; the scope was global by design; the tool simply never checked whether the question behind the answers was public. Any agent wired to the forum with a service key could read the content the moderation model exists to suppress — including pending-review material, which by definition nobody has approved for any audience yet.

The fix, read directly from the diff, is a new predicate applied at three call sites:

func mcpQuestionIsPublic(question *schema.QuestionInfoResp) bool { return question != nil && question.Show == entity.QuestionShow && (question.Status == entity.QuestionStatusAvailable || question.Status == entity.QuestionStatusClosed) }

MCPQuestionDetailHandler now refuses with “No question found.” unless the predicate holds; MCPAnswersHandler returns “[]” for missing question IDs and for non-public questions; MCPCommentsHandler resolves the object (falling back from question to answer to parent question via a new mcpObjectQuestionIsPublic helper) and returns “No comments found.” on failure. A new 50-line unit test pins the matrix: nil, hidden, deleted and pending all false; available and closed true. Before this change, the answers handler fetched by question ID with no visibility gate at all, and an empty question ID fell through to the general path instead of returning empty.

The generalisable point is one we keep filing: a machine-readable API re-implements the product’s access model from scratch, and the re-implementation is where the check gets dropped. The web UI knew these questions were hidden. The MCP tool was a second implementation of “who may read this,” written without the predicate. Every MCP server bolted onto an application with a non-trivial visibility model should be audited as a second front door, because that is what it is.

The rest of the batch: one theme, many paths

Read together, the siblings describe a visibility model enforced at the question page and nowhere else:

Non-public content through side channels. CVE-2026-68482: unauthenticated or unauthorised users could retrieve the invited-user list of a non-public question (CWE-862). CVE-2026-76994: unauthenticated attackers could obtain hidden-question metadata through public answer profiles (CWE-200). CVE-2026-79613: unauthenticated access to comments on non-public content through public user profiles (CWE-202). CVE-2026-79620: the similar-question search let authenticated users view non-public question metadata (CWE-202). CVE-2026-79633: missing authorisation checks let authenticated users act on non-public content (CWE-202). CVE-2026-90910: the reaction API neither enforced visibility on reads nor gated add/remove on the caller’s own reactions against it (CWE-306). Six endpoints, one missing predicate — the same shape as the MCP flaw, minus the agent angle.

Credentials and sessions. CVE-2026-64943 (CWE-532) is the batch’s second headline: full API keys were written to application logs on every authenticated request, so anyone with log-read access could recover and replay active bearer credentials. Pair that with the MCP finding and the blast radius composes: keys that unlock an over-permissive machine interface, lying in plaintext in a log store with its own (usually broader) readership. CVE-2026-79624 (CWE-613) records insufficient session invalidation: revoked users kept accessing known private uploaded files with a stale visit token. The diff shows the fix in RemoveUserTokens — visit-cache entries are now removed alongside access tokens, with the surviving token’s mapping explicitly preserved. CVE-2026-86589 (CWE-303) is subtler: a User Center login flaw could omit a new external user’s external identity from the session, letting subsequent requests bypass central account suspension or deletion checks until the session expired. The session remembered the user but forgot where the user came from, and the enforcement that depended on provenance silently passed.

Checks wired to the wrong thing. CVE-2026-64945 (CWE-863): the question operation controller gated hide/show on the unpin permission instead of the hide permission, so custom roles separating the two granted hiding power to anyone holding only question.unpin. The new controller test pins it with a case named exactly for the defect: “unpin does not authorize hide.” CVE-2026-67249 (CWE-863): a verification code issued for one email workflow could be accepted by another sensitive workflow because the code’s purpose was never enforced — the classic cross-context token acceptance, in a mailbox. CVE-2026-64944 (CWE-79): the importer persisted imported question bodies as raw HTML, bypassing the normal Markdown-to-HTML sanitisation path, yielding stored XSS rendered to all viewers including privileged users. Notably, the same release adds a global Content-Security-Policy middleware (default-src 'self', frame-ancestors 'none', object-src 'none', plus nosniff) — defence in depth arriving in the same train as the sanitisation fix.

What to do

Upgrade to 2.0.3. The release has been out since 9 October; the CVEs only made it machine-readable on 19 October, so scanners were blind for ten days — check what your tooling actually saw. Then do the two things the batch implies but no advisory states: rotate every API key that existed while request logging wrote them to disk (6.4‑style credential hygiene applies to vendor bugs too), and audit your log stores for bearer material before assuming rotation alone closes it. If you expose Answer’s MCP server to agents, treat 71563 as a prompt to re-derive what your agents could read before the patch — hidden, deleted and pending content served to a key holder leaves no distinctive error trace, just answers. And ask the batch’s general question of your own product: enumerate every path that renders an object — profiles, search snippets, reactions, exports, machine APIs — and check each one enforces the visibility rule, not just the page.

None of the thirteen is in the CISA KEV catalogue (checked directly, 1,749 entries, zero hits), and no exploitation has been reported. All thirteen carry oss-security announcements dated 16 October 2026 and fix guidance pointing at 2.0.3.

Our verification was read-only. All thirteen CVE identifiers, publication timestamps (2026-10-19T10:16:47Z–10:16:49Z), Received status, the security@apache.org source, CWE assignments, descriptions and oss-security references were read first-hand from the NVD 2.0 API; the mcpQuestionIsPublic predicate, its three call sites, the mcpObjectQuestionIsPublic helper, the new unit test matrix, the “unpin does not authorize hide” case, the RemoveUserTokens visit-cache fix and the CSP middleware were quoted verbatim from the v2.0.2-to-v2.0.3 comparison fetched via the GitHub API; the 2.0.3 release date (9 October 2026), repository metadata (15,699 stars, 1,375 forks, Go, pushed 15 October 2026, not archived) likewise from the GitHub API. KEV status was checked directly against the published catalogue. Brave Search was used for discovery only. We installed nothing, ran no Answer instance, held no API key, and executed no proof of concept.

Sources: