SUMMARY
The address 23.227.38.74 is present in the Google Threat Intelligence curated list
`iplist-known-malicious-ips`.
IP: 23.227.38.74
PTR: shops.myshopify.com
Whois: Shopify, Inc. — NetName SHOPIFY-NET, CIDR 23.227.32.0/19
This is core Shopify storefront / webhook infrastructure — the address that Shopify
stores resolve to — not a compromised host.
Because Google's own recommended predefined firewall rules for network firewall
policies include an egress deny rule with
`destThreatIntelligences = iplist-known-malicious-ips`, any customer who follows that
recommendation silently loses all outbound connectivity to Shopify. There is no
warning, no changelog and no alert: traffic simply starts being dropped.
OBSERVED BEHAVIOUR
Egress to 23.227.38.74:443 denied by the predefined threat-intelligence egress rule.
In one project, denies ran continuously for about five days before we noticed:
First DENY: 2026-08-19T21:34:45Z
Last DENY: 2026-08-24T22:38:44Z
Total: 11,998 denied connections
Date (UTC) Denied connections
2026-08-19 418
2026-08-20 5,594
2026-08-21 3,421
2026-08-22 571
2026-08-23 573
2026-08-24 1,421
This broke a live Shopify <-> ERP integration for the duration.
The listing is a clear statistical outlier. Over that window, in that project:
23.227.38.74 11,998 denies (93.7% of all egress denies
produced by that rule)
next most-hit destination 111 denies
No other address inside SHOPIFY-NET (23.227.32.0/19) was ever denied, which suggests
a single bad entry in the feed rather than a range-level classification.
EXPECTED BEHAVIOUR
23.227.38.74 is not classified as a known malicious IP, and egress to Shopify is not
denied by the predefined threat-intelligence rules.
HOW TO CONFIRM
In any project using the predefined threat-intelligence rules, in Cloud Logging:
logName="projects/PROJECT_ID/logs/compute.googleapis.com%2Ffirewall"
jsonPayload.rule_details.priority=PRIORITY_OF_THREAT_INTEL_EGRESS_DENY_RULE
jsonPayload.connection.dest_ip="23.227.38.74"
REQUESTS
1. Remove 23.227.38.74 from `iplist-known-malicious-ips`, and — if it can be shared —
what caused shops.myshopify.com to be added in the first place?
2. Change notification. Is there any mechanism to be notified when a curated Google
Threat Intelligence feed changes? A change made on Google's side broke production
traffic with no prior signal. This failure mode is available to every customer who
follows the recommended predefined rules, which makes it a systemic issue rather
than a one-off.
3. Feed introspection. Is there any read-only way to query the current contents of a
feed, even for audit purposes only? Without it, customers cannot tell whether a
false positive has been corrected, and a local workaround has to stay in place
indefinitely — silently re-opening the exposure the rule was meant to close.
4. Exclusion mechanism (feature request). The only exception mechanism the Cloud NGFW
documentation offers today is a "selective allow" rule at a higher precedence than
the threat-intelligence deny rule. That is a workaround, not an exclusion: it
permanently removes the destination from threat-intelligence evaluation, including
for every future threat the feed might legitimately catch on that address.
Cloud Armor exposes a real exclusion list for threat-intelligence lists. Please
consider the equivalent for Cloud NGFW.
5. Dispute process. We could not find one. Neither the Cloud NGFW threat intelligence
documentation nor the Cloud Armor equivalent states where the data in these feeds
comes from, nor describes any procedure for reporting a misclassification or
requesting review of an entry. The Cloud NGFW support page does not mention Issue
Tracker at all; the only channel it names is the documentation feedback form.
That is why this report is being filed here rather than through a proper channel.
Please point us at the right one — and, if there is none, please consider that a
finding in its own right: a curated feed that customers are told to enforce in
production, with no published provenance and no way to contest an entry, is
difficult to operate safely.
WORKAROUND CURRENTLY IN PLACE
A selective allow rule for that destination, evaluated before the threat-intelligence
deny rule — the mechanism the documentation recommends. Traffic has been normal since
2026-08-24T22:46Z.
The three requests above compound into one systemic problem, which is the real reason
for filing this:
- The feed changed and broke production traffic with no signal (request 2).
- The feed cannot be inspected, so there is no way to learn that the false positive
has been corrected (request 3).
- The only documented remedy is a permanent allow rule (request 4).
Taken together, the recommended response to a false positive is to permanently disable
threat-intelligence enforcement for the affected destination, with no signal that would
ever justify re-enabling it. Every false positive in a curated feed therefore leaves a
permanent hole in the security posture of every customer who hits it. That outcome
seems contrary to the intent of the predefined rules.
