Git protocol exposure is small in this measurement and still needs a write check
Git can transfer repository data over SSH, HTTP, or the native git:// protocol. The native transport is simple and useful for read-only mirrors, but it has no built-in authentication. In a count-only ZoomEye probe on 2026-11-13 around 22:45 UTC, service="git" returned 59 matches and port="9418" returned 3. The query scope was sub_type="all", page 1, page size 1.
The small counts are not a reason to ignore the protocol. They are a reminder that an internet-wide index may not classify a lightly used, banner-poor service well. The important review question is whether an owned listener allows receive-pack, because that can make a repository writable to anyone who can reach the port.
The protocol has no authentication layer
Git's pack protocol documentation states that the transport itself contains no authentication mechanisms. SSH can provide authentication around the Git process, and HTTPS can use the web server's authentication and authorization. The native Git transport does not supply those controls. If a server exposes git-daemon with receive-pack enabled, the documentation warns that the repository can be writable by anyone who can access the port.
The protocol count therefore needs a configuration review. A read-only public mirror may be intentional. A write-enabled repository on a public interface is a different decision. The scan cannot tell which service is enabled, what repository paths exist, or whether a network ACL limits the source.
Port 9418 is the conventional native transport port, but a server can use another port and a proxy can terminate the connection. The three port matches should not be treated as the complete native-Git population. The service count is also not a completeness proof because protocol identification can require a successful interaction.
Separate read and write authority
Inventory repositories served through native Git. Record the daemon configuration, the exported paths, whether git-upload-pack is enabled, and whether git-receive-pack is enabled. Review the daemon's export-all setting and path allowlist. If a repository needs write access, put it behind SSH or HTTPS with account-level authorization and audit logging.
Network controls should restrict native Git to the mirror or internal consumer networks that need it. Do not expose a general-purpose Git daemon to the internet merely because the port is uncommon. An attacker who can write to a repository can change source, build instructions, or release scripts even if the repository is not the production server.
For public read-only mirrors, verify that the exported tree is intended for publication and that no private repository is included by a broad path rule. Run a test clone from an unauthorised network and confirm that it fails. Then test the intended consumer path and record the repository and protocol.
Use the count as a prompt, not a conclusion
The 59 service matches and three port matches are evidence from one bounded query, not a census of all Git servers. Compare them with the organization's source-code inventory, its DNS records, and its internal network scans. A single internal host with a misconfigured daemon is enough to create a write path even if the global count is tiny.
Log the daemon configuration version, exported paths, source restrictions, and whether each repository is read-only. Avoid logging repository contents or credentials. Review the change when a mirror becomes writable, when a public port is added, or when a repository is moved between hosts.
Native Git remains valuable for mirrors and controlled consumers. The security decision is whether the listener is read-only, who can reach it, and whether write authority is protected by a layer that the Git transport does not provide.
Top comments (0)