Printers Stopped working yesterday 1/28 - Due to Snort rule blocking SNMP Public

[JohnPaul]

Yesterday we had many users report that their copiers were not working. This was due to SNORT rule 1-1412 being installed on 1/28/26. 

[alemabrahao]

I suggest you add the printer IP to the allow list and open a support case.

[JohnPaul]

Thanks, I did open a case. We had about 200 users call in. For now, whitelisting the rule worked. Just wanted to share in case someone else is trying to figure out why their printers are not working.

[bperezgo · Accepted solution]

The Snort version was updated to 3.9.6.0 via backend and triggered this. Engineering is aware and is currently investigating this. For now, whitelisting the rule is the recommended workaround. Wait up to an hour for the whitelist to take effect. 

[WayneTownship]

Could someone provide details on where to setup this whitelist?  We've been having issues with the printers across multiple print servers since last week.  I've been having to start and restart the print spooler on the server multiple times each day. 

[Jedijrobbie]

Easiest way to do it is Organization > Security Center

If you're being effected the Most prevalent threats box will have Protocol-SNMP public access tcp occurances happening. 


You can whitelist the rule from there as well as show the signature only

Once whitelisted it will show up under Security & SD-WAN > Configure > Threat Protection under Intrusion detection and prevention as an allow list rule. Allow for about 1 hour for the rule to solidify. 

[WayneTownship]

Thank you!

[JohnPaul]

Also, whitelisting the rule is organization-wide.

[WayneTownship]

I noticed that.  I had been planning on just putting it into place for one site and then seeing if that site stopped having problems while the other site continued to have issues.  But after applying the rule I flipped to the other site to check and noticed that the rule was applied there as well.  So I won't be able to test this, but if it makes the dozens of calls each day go away I'll be happy.

[JohnPaul]

Thank you for highlighting this issue—it's clearly affecting a lot of us. There must be hundreds of printers that are not working for customers because of the default "public" SNMP community string being blocked by Snort rule 1-1412 after the January 28, 2026 update. This is a major problem that Meraki needs to address promptly, especially since out-of-the-box printers on separate VLANs will run into the same snag if the rule is enabled, and many admins won't immediately know why printing fails. It's leading to significant time wastage troubleshooting what turns out to be a false positive in legitimate environments.

While whitelisting the rule works as a temporary fix, the lack of proactive communication from Meraki has been frustrating. Can we get an update from engineering on the status of a permanent resolution? Also, what steps have been taken so far to inform customers about this—such as alerts, dashboard notifications, or knowledge base articles—to prevent more widespread disruption?

[ThatOneGuy]

Can you let us know when it has been resolved by chance?

[bperezgo]

Hi,

This has been the latest update:  

We have determined that rule 1:1412 is generating false positives and the immediate recommendation is to whitelist it. The rule has been reviewed by our internal teams and will be removed in a future IDS/IPS ruleset update as it is more than 20 years old.

[xxxxxxxxxxxxxxx]

Related to this, when we started receiving tons of hits for 1:1412, we also started receiving some private access tcp alerts for rule 1:1414. Is this at all related to the issues going on with 1:1412?