Drafted 2026-04-23, ahead of the 2026-04-24 08:00 CEST public disclosure. Documents the decision to self-allocate vulnerability identifiers under the MOKSHA namespace and publish them at cna.moksha.dk, rather than wait indefinitely for MITRE to respond to the 15-day-old CVE reservation request.
I am issuing my own vulnerability advisories under the identifier scheme MOKSHA-YYYY-NNNN, hosted at cna.moksha.dk, cross-linkable to MITRE CVE IDs when and if MITRE ever assigns them.
CVE reservations for the 89 XAPI vulnerabilities were filed with MITRE on 2026-04-09. As of the public disclosure on 2026-04-24 08:00 CEST, 15 days later, MITRE has not responded with CVE IDs. Parallel filings to GCVE/CIRCL, ENISA, and DIVD have also received no response. CERT/CC notified 2026-04-23 (one day before release) as a courtesy and for potential CVE-assignment-of-last-resort; no response expected in time.
The vulnerabilities are real. The vulnerabilities are exploitable. The vulnerabilities have existed in production infrastructure for 16+ years. Every day they remain undisclosed is a day attackers with their own pattern-recognition have the advantage. Waiting longer for MITRE to process a 15-day-old reservation request is not a trade-off I am willing to make on behalf of every deployer of the affected software.
Independent security research exists because vendor-internal security engineering fails or under-invests. The CVE assignment system is supposed to be the neutral registration layer that makes independent research legible to the rest of the ecosystem. When that layer fails - through backlog, through institutional slowness, through any number of perfectly-understandable operational constraints - the practical question becomes: do researchers wait indefinitely, or do they publish anyway?
Waiting indefinitely means the research stays private while the vulnerabilities remain exploitable. Publishing anyway means the research is in the public record but lacks the canonical identifier system the ecosystem relies on.
Neither option is good. The third option is: issue identifiers yourself, in a namespace that is clearly yours, with a format that is schema-compatible with CVE JSON 5.1, and publish at a permanent URL under your own domain. When MITRE eventually catches up, you cross-link. The ecosystem gets both a MOKSHA-YYYY-NNNN and (later) a CVE-YYYY-NNNNN, pointing to the same underlying research.
This is not a rejection of MITRE. It is a refusal to let MITRE's operational state hold customer security hostage to bureaucratic latency.
Moksha, the one-person consulting company behind this disclosure, was named deliberately. Sanskrit: liberation from ego-identification and from the cycle of clinging to external validation. The operating thesis is that the work matters more than the approval of any gatekeeper - that independence from institutional slowness is not an accident of this business, it is the entire point.
Becoming one's own CNA is the logical extension of that thesis into the infrastructure of vulnerability disclosure itself. I am not asking MITRE for permission to document reality. I am documenting reality and giving it a permanent identifier under my own authority. The existence of MOKSHA identifiers does not diminish CVE identifiers. They coexist. The ecosystem benefits from both.
Format: MOKSHA-YYYY-NNNN
MOKSHA - namespace prefix, unambiguously identifies the issuing authority as Moksha (the company)YYYY - four-digit year of publicationNNNN - four-digit zero-padded sequence number within the yearZero-padding is for sort-stability in filesystems and tooling. Four digits give 9999 slots per year, which should be comfortable for single-researcher capacity.
For the 2026-04-24 disclosure: MOKSHA-2026-0001 through MOKSHA-2026-0089, one per finding, corresponding to the 89 independently exploitable vulnerabilities identified in the 9-week XAPI audit. Where there is a semantic ID in the research (BOC-1, SMC-1, etc.), the published advisory references both: the MOKSHA ID for citation and the semantic ID for technical context.
https://cna.moksha.dk/https://cna.moksha.dk/MOKSHA-2026-0001https://cna.moksha.dk/MOKSHA-2026-0001.json (CVE JSON Schema 5.1)https://cna.moksha.dk/feed.xmlhttps://cna.moksha.dk/aboutStatic HTML + static JSON. Zero webapp, zero JavaScript, zero external dependencies. Same attack-surface posture as shittrix.moksha.dk.
CVE JSON Schema 5.1 (MITRE's current record format), with MOKSHA identifiers in the cveMetadata.cveId field. When MITRE eventually assigns a CVE ID, the advisory's JSON is updated with a supplementary cveMetadata.alternateIds field cross-referencing the CVE-YYYY-NNNNN.
Schema-compatibility means standard tooling (NVD feeds, SCA tools, vulnerability scanners, security feeds) can consume MOKSHA records with minimal adaptation. The identifier is non-standard; the data shape is not.
For each MOKSHA advisory, the page shows:
Self-allocated advisory identifiers are not novel. Every major independent research group maintains its own numbering scheme alongside the CVE program:
MSRC-, APPLE-HT, GHSA- for GitHub, etc.) - self-issued advisory numbering by entities that are also MITRE CNAs but maintain their own parallel scheme.MOKSHA-YYYY-NNNN is the same pattern, scoped to the output of one researcher operating as a single-person company.
I am not adversarial to MITRE. MITRE operates the CVE program competently given its budget and the volume it processes. The 15-day non-response on 89 CVE reservations from one researcher is not an indictment of MITRE; it is an indictment of the resource constraints under which the CVE program operates. When MITRE eventually assigns CVE IDs for these vulnerabilities, the MOKSHA advisories will be updated with the CVE IDs cross-referenced. The two identifier systems will coexist.
I would welcome MITRE or any CNA reaching out to accelerate assignment for these 89 cases. The offer of the supporting research materials (advisories, PoCs, evidence logs, detection rules) to CSIRTs and accredited coordinators remains open.
Beyond the 2026-04-24 disclosure:
cna.moksha.dk persists as the durable publication venue for future Moksha research.The work happens at the pace of the work, not at the pace of the ecosystem's paperwork. Moksha issues its own identifiers because the vulnerabilities do not wait for committees.