Permissions not properly checked in Invenio-Drafts-Resources
Published Dec 6, 2021 · Updated Nov 3, 2026
Original summary
Normalized public record · Updated Nov 3, 2026
Permissions not properly checked in Invenio-Drafts-Resources
Publisher and source text is retained separately from QFinch interpretation.
QFinch assessment
Invenio-Drafts-Resources does not properly check permissions when a record is published. The vulnerability is exploitable in a default installation of InvenioRDM. An authenticated user is able via REST API calls to publish draft records of other users if they know the record identifier and the draft validates (e.g. all require fields filled out). An attacker is not able to modify the data in the record, and thus e.g. *cannot* change a record from restricted to public.
Potential impact
Invenio-Drafts-Resources does not properly check permissions when a record is published. The vulnerability is exploitable in a default installation of InvenioRDM. An authenticated user is able via REST API calls to publish draft records of other users if they know the record identifier and the draft validates (e.g. all require fields filled out). An attacker is not able to modify the data in the record, and thus e.g. cannot change a record from restricted to public.
Technical context
The service's publish() method contains the following permission check: However, the record should have been passed into the permission check so that the need generators have access to e.g. the record owner. The bug is activated in Invenio-RDM-Records which has a need generator called RecordOwners(), which when no record is passed in defaults to allow any authenticated user:
Evidence: public source recordsAffected products
| Affected package, product or range | Fix status |
|---|---|
| Consult the referenced vendor advisory for affected versions. | Consult source advisory |
Matching a version is only one part of assessing exposure. QFinch has not assessed your environment on this public page.
Remediation
Apply the vendor-supported fixed release or mitigation, then verify the affected component is no longer reachable.
- Confirm the affected product and reachable code path exist in your environment.
- Apply the vendor-supported patch or mitigation from the primary advisory.
- Rescan the exact deployed revision and retain verification evidence.
Evidence coverage
- SSVC priority
- LOW
- Confidence
- Not available
- Aliases
- None reported
Scores appear only when corresponding evidence exists. Missing data is never interpreted as zero risk.
Sources and record history
Record history
Published Dec 6, 2021 · Last refreshed Nov 3, 2026