This message was deleted.

The module files are usually downloaded if you had a pom or ivy file with the marker that there is a GMM file. And I think it would only download the GMM file from the very same repository. If you of course have a Nexus group repo that forwards to several proxy repos without restrictions, it could happen that the GMM file is then served by a different repository. We here mitigate that risk with routing rules in the Nexus repos that explicitly allow which dependency can be downloaded from which upstream respository. If you mean that the html page downloaded has some JavaScript redirect logic or similar, I highly doubt Gradle would follow that. It does not expect an HTML page that it interprets, it expects a GMM file. But don't take my word for it.

Yeah, I would have been surprised if gradle would do that, but that's the attack attempt I suspect behind this. If you want to see such a malicious module, you can download one from http://maven.ecs.soton.ac.uk/content/groups/maven.openimaj.org/org/springframework/amqp/spring-amqp-bom/3.0.6/spring-amqp-bom-3.0.6.module

Ah, with a

window.location.replace

JavaScript snippet. I really don't think Gradle would in any way handle that.

How sure are you? And is there a simple way to verify that?

Just a distinct gut feeling

The module metadata is a JSON file, but with a

.module

file extension https://github.com/gradle/gradle/blob/master/subprojects/docs/src/docs/design/gradle-module-metadata-latest-specification.md If the file isn't JSON then I doubt Gradle would do anything apart from fail the parsing. More generally, perhaps the attacker is hoping that the Maven repo gets indexed by Google and the file appears in search results?