[#48078] - reject non-http(s) schemes in FeedFactory::getFeed
- Closed
- 11 Jul 2026
- Medium
- Build: 5.4-dev
- # 48078
- Diff
- arib06:feedfactory-uri-scheme
User tests: Successful: Unsuccessful:
- I read the Generative AI policy and my contribution is either not created with the help of AI or is compatible with the policy and GNU/GPL 2 or later.
Summary of Changes
FeedFactory::getFeed() passes the feed URI straight to XMLReader::open() without checking its scheme. XMLReader::open() honours PHP stream wrappers, so a stored feed URL such as file:///etc/passwd, php://filter/... or compress.zlib://... is opened locally, and an http(s):// value pointing at an internal host reaches that host from the server. The URI reaches this helper from the news feed link field (com_newsfeeds) and the feed module URL (mod_feed), and the fetch happens when a normal front-end visitor views the feed. Restricting the URI to the http and https schemes inside getFeed() covers every caller in one place instead of each one having to pre-validate.
Testing Instructions
Create a News Feed under Components > News Feeds with the Link set to file:///etc/passwd, assign it to a menu item, then open that menu item on the site front end.
Actual result BEFORE applying this Pull Request
The local path is opened through the XMLReader stream wrapper. Any non-http(s) scheme (file://, php://, compress.zlib://, ftp://, ...) is accepted and fetched.
Expected result AFTER applying this Pull Request
Only http and https feed URLs are fetched. Any other scheme is rejected with an InvalidArgumentException before the URI reaches XMLReader::open().
Link to documentations
Please select:
-
Documentation link for guide.joomla.org:
-
No documentation changes for guide.joomla.org needed
-
Pull Request link for manual.joomla.org:
-
No documentation changes for manual.joomla.org needed
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | Libraries Unit Tests |
@arib06 Have you really tested your PR yourself like described in your testing instructions?
Our contribution guidelines require that PR authors test their PRs before submitting.
When proceeding like you described with feed URL file:///etc/passwd with a Linux web server where that file exists, I get:
Another thing is that there could be valid use cases for using other sources than http or https for a news feed, e.g. ftp or a local XML file. Your PR breaks this, so from a funtional point of view your PR is a hard b/c break which cannot be done with a patch version (5.4.x or 6.1.x) due to semantic versioning.
Finally, you have again forgotten to check the AI policy check box. That's the third time now.
@arib06 Have you really tested your PR yourself like described in your testing instructions?
Our contribution guidelines require that PR authors test their PRs before submitting.
When proceeding like you described with feed URL file:///etc/passwd with a Linux web server where that file exists, I get:
Another thing is that there could be valid use cases for using other sources than http or https for a news feed, e.g. ftp or a local XML file. Your PR breaks this, so from a functional point of view your PR is a hard b/c break which cannot be done with a patch version (5.4.x or 6.1.x) due to semantic versioning.
Finally, you have again forgotten to check the AI policy check box. That's the third time now.
You're right on both counts. I retested and file:///etc/passwd doesn't actually disclose anything: XMLReader opens the path but the read/parse step fails since it isn't valid XML, so you get the error in your screenshot rather than the file contents. My testing instructions overstated the impact. And restricting getFeed() to http/https does break legitimate ftp or local-file feeds, which is a b/c break that shouldn't go into a patch release. Closing this one. Sorry for the noise, and I've ticked the policy box.
| Status | Pending | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2026-07-11 09:49:12 |
| Closed_By | ⇒ | arib06 | |
| Labels |
Added:
Unit/System Tests
PR-5.4-dev
|
||
@arib06 #48056 (comment)