Intigriti Challenge July 2026

Contents hide

1 Improper Authorization checks in ‘Create Manifest’

2 Summary

3 Steps To Reproduce

3.1 Login

3.2 Update the manifest

3.3 Create manifest outside of the namespace

3.4 Exploitation

3.5 Result

4 Impact

5 Recommended solution

Improper Authorization checks in ‘Create Manifest’

Summary

An authorization flaw exists in the ‘Manifest Studio’ functionality in the Registry Observatory app `https://challenge-0726.intigriti.io/challenge.html‘.

A user with malicious intent can create a manifest for + view details about packages not part of their own namespace. Potentially sensitive information like the release notes (with a flag in it 🙂 can be revealed.

When creating a new manifest, one can specify the ‘scope’ which refers to the namespace the package is part of. This value is passed to the server in a parameter called ‘manifest_b64’.
The information inside the ‘manifest_b64’ contains the package details including scope definition, and this is by default the namespace value of the current namespace, like for example ‘skyw1per-6a470cf1’ for my account.

By injecting this JSON formatted data with two packages with both different details, something interesting occurs. The application appears to perform its security boundary checks based on the first package entry, but the second package entry is used in publication.
By specifying a different (existing) package and scope for the second package, a publication can be created for an existing package outside of your own namespace.

Steps To Reproduce

Login

Update the manifest

Update the manifest for the Hello World package:
Browse to Manifest Studio

Create a manifest for the package ‘hello-world’ by first clicking on Request Approval and second on Run preflight. Capture these requests in BurpSuite of Caido.

This is an example of the intended usage of this feature.
With a successful attempt, the result is visible under Publication History.

Create manifest outside of the namespace

Demonstrating the Security boundary: Attempt to create manifest for a package outside of own namespace. Look in Burpsuite / Caido History for the request to endpoint /api/manifests/sign which is the POST request made when the request approval button from step 2 is clicked.

Base64 decoded manifest_b64 value:

{
  "package": {
    "scope": "skyw1per-6a470cf1",
    "name": "hello-world",
    "version": "1.0.0"
  },
  "metadata": {
    "description": "Compatibility check",
    "visibility": "private"
  },
  "operation": "preflight"
}

Lets change name to security-notes and scope to core.
Based on this comment and details, we know this other namespace and package should exist within the application.

After applying the changes, base64 encode the entire JSON object and replace the manifest_b64 value in your request.

Expected result: A 401 response with the following error message:

Exploitation

Exploitation: Adding two json packages to the payload
Send the request to /api/manifests/sign to repeater again. This time, lets use the following payload:

{
  "package": {
    "scope": "skyw1per-6a470cf1",
    "name": "hello-world",
    "version": "1.0.0"
  }, "package": {
    "scope": "core",
    "name": "security-notes",
    "version": "1.0.0"
  },
  "metadata": {
    "description": "Compatibility check 123 test",
    "visibility": "private"
  },
  "operation": "preflight"
}

Note this payload contains two sets of package details. The first one will be used for validation, and should check all requirements. the second one is the one used in the actual publication.
After applying the changes, base64 encode the entire JSON object and replace the manifest_b64 value in your request.
Expected result: a 200 response with approval_id,manifest_sha256,nonce,expires_at and signature.

Next, locate the POST request to /api/publications and edit it in Repeater. For the manifest_b64 body, use the same value as in the previous request. The other required parameters can be copied from the HTTP response of /api/manifests/sign.

Expected result: HTTP 201 response.

Result

Browse in the application to Publication History.
The last created item should be the core/security-notes package, indicating the exploit has been successful.

The release notes from this package are readable:

FLAG:

INTIGRITI{019f8700-4613-74fb-923e-781903e4bee9}

Impact

A user with malicious intent can publish a manifest for a package outside of their own namespace.
Due to this, a new version under “publication history” is created.
The user can view details of this package like the original release notes.
All they need to know is the namespace and the name of the package, no user interaction is required.