Metasploit ships a module for a GitLab file read exploited in the wild
Serguey Asael Shinder2 min readThis week's Metasploit release carries five new modules, one enhanced module, one feature and nine bug fixes - and one item that the team tells readers to stop reading and act on. Self-hosted GitLab has an unauthenticated arbitrary file read that is being exploited in the wild, affecting versions from 18.7 up to the fixed releases. There is no mitigating clause in how Rapid7 words it: no credentials needed, attacks observed, patch now.
The second addition deserves attention even though nothing is on fire. Metasploit now has native mitm6-style modules for DHCPv6 and IPv6 Router Advertisement DNS takeover - that is, becoming the DNS server for a Windows network by answering on the IPv6 stack that was never configured, is not used, and was never disabled either. Windows will accept a new DNS server from whoever offers one. Until now this was a job for external tooling; it is now in the framework everyone already has.
The wrap-up comes from Belgium, where the team was at a conference; one of their own, @jburgess-r7, presented 0day research.
What it means
The GitLab bug belongs to the worst-shaped class there is for a self-hosted service: unauthenticated, read-only in the boring sense and devastating in practice, and now with a module in the most widely installed exploitation framework in existence. The window between "public module" and "opportunistic scanning" is short, and an arbitrary file read on a GitLab host does not stop at source code - it reaches CI configuration, tokens on disk, and whatever the runner was trusted with. If your instance is on-prem and in that version range, this is the one thing on the page with a deadline.
The IPv6 modules are the item to think about structurally rather than urgently, because they attack a configuration nobody made. Every rule in a Windows environment about who may be a DNS server is generally written for IPv4; the v6 stack is enabled by default, unmonitored because unused, and will happily take instruction from a stranger on the local segment. That is the same failure pattern as an unvalidated security control elsewhere in this week's news - the visible half was configured, and the half nobody looked at was the one that decided. Worth checking whether your network's IPv6 story is "deliberately configured" or "present because it shipped that way", because the second answer is now a module away from being someone else's DNS.