From W3C Wiki
Access to local resources
OpenSP will read only such files that the calling application tells it to read and those that constitute external parsed entities which means in order to exploit it the attacker would need to
- compromise the server changing
- check or its dependencies
- one of the relevant SGML catalogs
- one of the relevant DTDs
if that happens, the attacker will most likely have sufficient privileges on the server to disable -R or work around it which means -R does not mitigate this problem
- inject references to external parsed entities that resolve to local resources through
- formal system identifiers such as `<OSFILE>` or `<OSFD>`
- certain URI schemes like 'file'. OpenSP does not support such schemes as far as I can tell.
- bugs in the 'http' resolver, for example it might consider `http://www.example.org/../../foo` to refer to `file:///foo`, -R would help is this unlikely case
- a reference to a well-known local resource available through a supported scheme like http://intranet/
- bugs in the calling application like
- HTTP resources as written to disk changing the base URI to a 'file' one which then needs to be overridden in order to properly resolve the external entity at all.