Consider the following slightly modified access log line from the first regex test:

3.3.3.3 - - [20/May/2015:21:05:01 +0000] "GET /723.3.3.357 HTTP/1.1" 200 13358 "-" "useragent"

The requested URI could be an OID from an SNMP MIB or something like that.

The current implementation would replace the 3.3.3.3 in that URI, even though it has nothing to do with the client IP address and isn't, in fact, an IP address at all:

3.3.0.0 - - [20/May/2015:21:05:01 +0000] "GET /723.3.0.057 HTTP/1.1" 200 13358 "-" "useragent"'

Note that this depends on the real client address being contained in the URI. The following line

2.2.2.2 - - [20/May/2015:21:05:01 +0000] "GET /723.3.3.357 HTTP/1.1" 200 13358 "-" "useragent"

doesn't modify the URI:

2.2.0.0 - - [20/May/2015:21:05:01 +0000] "GET /723.3.3.357 HTTP/1.1" 200 13358 "-" "useragent"

Hence this could even reveal the real client IP address if only 723.3.3.357 makes sense in that place, and 723.3.0.057 doesn't.

I'll open a PR in a minute that - among other things - addresses this problem by only replacing the groups where they actually matched and modifies the first test case to highlight this problem.