Security Policy

Reporting a Vulnerability

Please do not report security vulnerabilities through public GitHub issues. Use GitHub’s private vulnerability reporting instead: go to the Security tab and click Report a vulnerability, or write to jim.jones@uni-muenster.de.

It helps if you can include the rdf_fdw, PostgreSQL, libcurl and libxml2 versions in use, the server and foreign table options involved, and the SQL needed to reproduce the problem — with any real credentials redacted.

rdf_fdw is maintained by one person alongside other work. You will get an answer as soon as I can manage, and I will keep you posted on the progress of a fix.

Supported Versions

Fixes are made on the main branch and go out in the next release; there are no backports to earlier ones. If you are running an older version, the first step is to upgrade.

What Counts as a Vulnerability

rdf_fdw treats a remote SPARQL endpoint as untrusted. Anything it sends back — response bodies, headers, redirects, error pages — must not be able to crash the backend, corrupt data, exhaust server resources, or leak the credentials stored in a USER MAPPING. This holds even for an endpoint you trust, since it may be compromised or impersonated. Likewise, a user who can query a foreign table should not be able to bend the generated SPARQL beyond what the pushdown rules intend, or write through a server marked readonly.

Setting up a foreign server, on the other hand, already requires privileges that allow a lot within the database, so pointing rdf_fdw at a deliberately malicious endpoint is not in itself a vulnerability. Bugs in PostgreSQL, libcurl or libxml2 belong to those projects — though rdf_fdw using them unsafely belongs here.

Fixes are released before the details are published, and the CHANGELOG credits reporters by name unless they prefer otherwise.