Impact
In the OCI Distribution Specification version 1.0.0 and prior, the Content-Type header alone was used to determine the type of document during push and pull operations. Documents that contain both “manifests” and “layers” fields could be interpreted as either a manifest or an index in the absence of an accompanying Content-Type header. If a Content-Type header changed between two pulls of the same digest, a client may interpret the resulting content differently.
Patches
The OCI Distribution Specification will be updated to require that a mediaType value present in a manifest or index match the Content-Type header used during the push and pull operations.
Workarounds
Clients pulling from a registry may distrust the Content-Type header and reject an ambiguous document that contains both “manifests” and “layers” fields or “manifests” and “config” fields.
References
GHSA-77vh-xpmg-72qh
For more information
If you have any questions or comments about this advisory:
jonjohnsonjr Analyst
Impact
In the OCI Distribution Specification version 1.0.0 and prior, the Content-Type header alone was used to determine the type of document during push and pull operations. Documents that contain both “manifests” and “layers” fields could be interpreted as either a manifest or an index in the absence of an accompanying Content-Type header. If a Content-Type header changed between two pulls of the same digest, a client may interpret the resulting content differently.
Patches
The OCI Distribution Specification will be updated to require that a
mediaTypevalue present in a manifest or index match the Content-Type header used during the push and pull operations.Workarounds
Clients pulling from a registry may distrust the Content-Type header and reject an ambiguous document that contains both “manifests” and “layers” fields or “manifests” and “config” fields.
References
GHSA-77vh-xpmg-72qh
For more information
If you have any questions or comments about this advisory: