CVE-2026-48053

Kolibri is an offline-first education platform. Prior to version 0.19.4, several Kolibri API endpoints accept an unvalidated baseurl parameter and fetch attacker-controlled URLs from the Kolibri server, reflecting the response body back to the caller. The original report identified two endpoints on the RemoteFacilityUser* viewsets; remediation review found two further reflection points on the same pattern. The GET endpoint was unauthenticated. Version 0.19.4 fixes the vulnerability.

Kolibri is an offline-first education platform. Prior to version 0.19.4, several Kolibri API endpoints accept an unvalidated baseurl parameter and fetch attacker-controlled URLs from the Kolibri server, reflecting the response body back to the caller. The original report identified two endpoints on the RemoteFacilityUser* viewsets; remediation review found two further reflection points on the same pattern. The GET endpoint was unauthenticated. Version 0.19.4 fixes the vulnerability.

Summary

Several Kolibri API endpoints accept an unvalidated baseurl parameter and fetch attacker-controlled URLs from the Kolibri server, reflecting the response body back to the caller. The original report identified two endpoints on the RemoteFacilityUser* viewsets; remediation review found two further reflection points on the same pattern. The GET endpoint was unauthenticated.

Affected endpoints

Reported:

• GET /api/auth/remotefacilityuser → RemoteFacilityUserViewset (kolibri/core/auth/api.py:1570). No authentication required.
• POST /api/auth/remotefacilityauthenticateduserinfo → RemoteFacilityUserAuthenticatedViewset (kolibri/core/auth/api.py:1594). Authentication is checked against the remote server rather than the local Kolibri.

Found during remediation:

• POST /api/public/setupwizard/loddata → setup wizard's remote-signup proxy (kolibri/plugins/setup_wizard/api.py). Reachable on unprovisioned devices.
• GET /api/public/networklocation/<id>/facilities/ → NetworkLocationFacilitiesView (kolibri/core/discovery/api.py). Authenticated but with the same Response(remote_payload) pattern.

Root cause

Two compounding issues:

1. Response reflection — these endpoints returned the remote server's JSON body more or less verbatim to the caller (Response(response.json()), Response(facility_info["users"]), etc.).
2. No restriction on the remote target — baseurl was validated only by URLValidator(schemes=["http", "https"]). NetworkClient.build_for_address() would connect to any host with a valid Kolibri-shaped /api/public/info/ response, and requests followed 30x redirects by default, so a hostile peer could pivot the fetch to an arbitrary host (cloud metadata, internal services) before reflection.

Two reflection vectors

GET vector (RemoteFacilityUserViewset): The viewset fetched <baseurl>/api/public/facilitysearchuser/ and returned Response(response.json()). An attacker-controlled baseurl returned a 302 to an arbitrary internal URL; requests followed the redirect, and the redirected response body was returned to the attacker.

POST vector (RemoteFacilityUserAuthenticatedViewset): get_remote_users_info() fetched <baseurl>/api/public/facilityuser/ with Basic Auth and the viewset returned Response(facility_info["users"]). A malicious baseurl returned crafted user-shaped JSON; arbitrary smuggled fields were reflected back to the caller. The setup wizard and NetworkLocationFacilitiesView endpoints had the same shape on different remote URLs.

Reproduction

The vulnerability can be reproduced by pointing baseurl at an attacker-controlled HTTP server that:

1. Responds to GET /api/public/info/ with a valid Kolibri info payload (so NetworkClient.build_for_address() succeeds).
2. GET vector: responds to GET /api/public/facilitysearchuser/ with a 302 redirect to the target URL. The redirected response body is reflected via Response(response.json()).
3. POST vector: responds to the relevant remote URL with crafted JSON containing additional fields. The full JSON is reflected.

A working PoC has been retained internally and is not published with this advisory.

Demonstrated impact (pre-fix)

• Unauthenticated outbound requests from the Kolibri server to any HTTP(S) URL the attacker chose (GET endpoint only; the others required auth or an unprovisioned device).
• Reflected data exfiltration for any HTTP endpoint that responded to a plain GET with JSON and no special request headers.
• Cloud metadata reachability was realistic but service-specific:
  • AWS IMDSv1 — reachable
  • DigitalOcean (/metadata/v1.json) — reachable
  • GCP, Azure, AWS IMDSv2 — not reachable via this vector (require Metadata-Flavor / Metadata / token headers that the attacker could not inject)
• Reachability of internal HTTP services on the same network as the Kolibri server, with their JSON responses…

Kolibri is an offline-first education platform. Prior to version 0.19.4, several Kolibri API endpoints accept an unvalidated baseurl parameter and fetch attacker-controlled URLs from the Kolibri server, reflecting the response body back to the caller. The original report identified two endpoints on the RemoteFacilityUser* viewsets; remediation review found two further reflection points on the same pattern. The GET endpoint was unauthenticated. Version 0.19.4 fixes the vulnerability.

Kolibri is an offline-first education platform. Prior to version 0.19.4, several Kolibri API endpoints accept an unvalidated baseurl parameter and fetch attacker-controlled URLs from the Kolibri server, reflecting the response body back to the caller. The original report identified two endpoints on the RemoteFacilityUser* viewsets; remediation review found two further reflection points on the same pattern. The GET endpoint was unauthenticated. Version 0.19.4 fixes the vulnerability.

Summary

Several Kolibri API endpoints accept an unvalidated baseurl parameter and fetch attacker-controlled URLs from the Kolibri server, reflecting the response body back to the caller. The original report identified two endpoints on the RemoteFacilityUser* viewsets; remediation review found two further reflection points on the same pattern. The GET endpoint was unauthenticated.

Affected endpoints

Reported:

• GET /api/auth/remotefacilityuser → RemoteFacilityUserViewset (kolibri/core/auth/api.py:1570). No authentication required.
• POST /api/auth/remotefacilityauthenticateduserinfo → RemoteFacilityUserAuthenticatedViewset (kolibri/core/auth/api.py:1594). Authentication is checked against the remote server rather than the local Kolibri.

Found during remediation:

• POST /api/public/setupwizard/loddata → setup wizard's remote-signup proxy (kolibri/plugins/setup_wizard/api.py). Reachable on unprovisioned devices.
• GET /api/public/networklocation/<id>/facilities/ → NetworkLocationFacilitiesView (kolibri/core/discovery/api.py). Authenticated but with the same Response(remote_payload) pattern.

Root cause

Two compounding issues:

1. Response reflection — these endpoints returned the remote server's JSON body more or less verbatim to the caller (Response(response.json()), Response(facility_info["users"]), etc.).
2. No restriction on the remote target — baseurl was validated only by URLValidator(schemes=["http", "https"]). NetworkClient.build_for_address() would connect to any host with a valid Kolibri-shaped /api/public/info/ response, and requests followed 30x redirects by default, so a hostile peer could pivot the fetch to an arbitrary host (cloud metadata, internal services) before reflection.

Two reflection vectors

GET vector (RemoteFacilityUserViewset): The viewset fetched <baseurl>/api/public/facilitysearchuser/ and returned Response(response.json()). An attacker-controlled baseurl returned a 302 to an arbitrary internal URL; requests followed the redirect, and the redirected response body was returned to the attacker.

POST vector (RemoteFacilityUserAuthenticatedViewset): get_remote_users_info() fetched <baseurl>/api/public/facilityuser/ with Basic Auth and the viewset returned Response(facility_info["users"]). A malicious baseurl returned crafted user-shaped JSON; arbitrary smuggled fields were reflected back to the caller. The setup wizard and NetworkLocationFacilitiesView endpoints had the same shape on different remote URLs.

Reproduction

The vulnerability can be reproduced by pointing baseurl at an attacker-controlled HTTP server that:

1. Responds to GET /api/public/info/ with a valid Kolibri info payload (so NetworkClient.build_for_address() succeeds).
2. GET vector: responds to GET /api/public/facilitysearchuser/ with a 302 redirect to the target URL. The redirected response body is reflected via Response(response.json()).
3. POST vector: responds to the relevant remote URL with crafted JSON containing additional fields. The full JSON is reflected.

A working PoC has been retained internally and is not published with this advisory.

Demonstrated impact (pre-fix)

• Unauthenticated outbound requests from the Kolibri server to any HTTP(S) URL the attacker chose (GET endpoint only; the others required auth or an unprovisioned device).
• Reflected data exfiltration for any HTTP endpoint that responded to a plain GET with JSON and no special request headers.
• Cloud metadata reachability was realistic but service-specific:
  • AWS IMDSv1 — reachable
  • DigitalOcean (/metadata/v1.json) — reachable
  • GCP, Azure, AWS IMDSv2 — not reachable via this vector (require Metadata-Flavor / Metadata / token headers that the attacker could not inject)
• Reachability of internal HTTP services on the same network as the Kolibri server, with their JSON responses…

Summary

Several Kolibri API endpoints accept an unvalidated baseurl parameter and fetch attacker-controlled URLs from the Kolibri server, reflecting the response body back to the caller. The original report identified two endpoints on the RemoteFacilityUser* viewsets; remediation review found two further reflection points on the same pattern. The GET endpoint was unauthenticated.

Affected endpoints

Reported:

• GET /api/auth/remotefacilityuser → RemoteFacilityUserViewset (kolibri/core/auth/api.py:1570). No authentication required.
• POST /api/auth/remotefacilityauthenticateduserinfo → RemoteFacilityUserAuthenticatedViewset (kolibri/core/auth/api.py:1594). Authentication is checked against the remote server rather than the local Kolibri.

Found during remediation:

• POST /api/public/setupwizard/loddata → setup wizard's remote-signup proxy (kolibri/plugins/setup_wizard/api.py). Reachable on unprovisioned devices.
• GET /api/public/networklocation/<id>/facilities/ → NetworkLocationFacilitiesView (kolibri/core/discovery/api.py). Authenticated but with the same Response(remote_payload) pattern.

Root cause

Two compounding issues:

1. Response reflection — these endpoints returned the remote server's JSON body more or less verbatim to the caller (Response(response.json()), Response(facility_info["users"]), etc.).
2. No restriction on the remote target — baseurl was validated only by URLValidator(schemes=["http", "https"]). NetworkClient.build_for_address() would connect to any host with a valid Kolibri-shaped /api/public/info/ response, and requests followed 30x redirects by default, so a hostile peer could pivot the fetch to an arbitrary host (cloud metadata, internal services) before reflection.

Two reflection vectors

GET vector (RemoteFacilityUserViewset): The viewset fetched <baseurl>/api/public/facilitysearchuser/ and returned Response(response.json()). An attacker-controlled baseurl returned a 302 to an arbitrary internal URL; requests followed the redirect, and the redirected response body was returned to the attacker.

POST vector (RemoteFacilityUserAuthenticatedViewset): get_remote_users_info() fetched <baseurl>/api/public/facilityuser/ with Basic Auth and the viewset returned Response(facility_info["users"]). A malicious baseurl returned crafted user-shaped JSON; arbitrary smuggled fields were reflected back to the caller. The setup wizard and NetworkLocationFacilitiesView endpoints had the same shape on different remote URLs.

Reproduction

The vulnerability can be reproduced by pointing baseurl at an attacker-controlled HTTP server that:

1. Responds to GET /api/public/info/ with a valid Kolibri info payload (so NetworkClient.build_for_address() succeeds).
2. GET vector: responds to GET /api/public/facilitysearchuser/ with a 302 redirect to the target URL. The redirected response body is reflected via Response(response.json()).
3. POST vector: responds to the relevant remote URL with crafted JSON containing additional fields. The full JSON is reflected.

A working PoC has been retained internally and is not published with this advisory.

Demonstrated impact (pre-fix)

• Unauthenticated outbound requests from the Kolibri server to any HTTP(S) URL the attacker chose (GET endpoint only; the others required auth or an unprovisioned device).
• Reflected data exfiltration for any HTTP endpoint that responded to a plain GET with JSON and no special request headers.
• Cloud metadata reachability was realistic but service-specific:
  • AWS IMDSv1 — reachable
  • DigitalOcean (/metadata/v1.json) — reachable
  • GCP, Azure, AWS IMDSv2 — not reachable via this vector (require Metadata-Flavor / Metadata / token headers that the attacker could not inject)
• Reachability of internal HTTP services on the same network as the Kolibri server, with their JSON responses…