The client has been able to include server side resources into the request by using external entities. By creating a custom XML message and sending it to the XML-RPC handling service it is possible to get the contents of files stored on the server's file system as part of the response.
Sure that version 2.x is affected?
Well no, the advisory states specifically 3.1 being the fix, but no definite version being the culprit.
Thanks for the bugs, Michael. Please feel free to add maintainers (maintainers: we'll keep him honest.)
+ 30 Aug 2014; Johann Schmitz <ercpe@gentoo.org> +xmlrpc-3.1.3.ebuild: + Version bump wrt bug #339400 Note that at least dev-java/jcs isn't compatible with the 3.1.3 version.
(In reply to Johann Schmitz (ercpe) from comment #4) > + 30 Aug 2014; Johann Schmitz <ercpe@gentoo.org> +xmlrpc-3.1.3.ebuild: > + Version bump wrt bug #339400 > Thanks for version bump > Note that at least dev-java/jcs isn't compatible with the 3.1.3 version. Can you file a separate bug for that and make it a blocker for this bug?
*** Bug 339400 has been marked as a duplicate of this bug. ***
Stabilization was done in another bug.
epsilon ~ # equery d -a dev-java/xmlrpc * These packages depend on dev-java/xmlrpc: dev-java/jcs-1.2.7.9-r1 (dev-java/xmlrpc:0) dev-java/jcs-1.3-r1 (dev-java/xmlrpc:0) dev-util/deskzilla-1.7.1-r1 (>=dev-java/xmlrpc-2.0.1) + 15 Jun 2015; Patrice Clement <monsieurp@gentoo.org> -jcs-1.2.7.9-r1.ebuild, + -jcs-1.3-r1.ebuild: + Remove vulnerable versions. Fix security bug 385811. + Clean up done.
Sorry there was nothing vulnerable about jcs. I just got mixed up with another bug title (#521736). + 15 Jun 2015; Patrice Clement <monsieurp@gentoo.org> -xmlrpc-2.0.1.ebuild: + Remove vulnerable version. Fix security bug 385811. + Clean up *really* done this time around.
GLSA Vote: No
GLSA Vote: No, closing