Almost a year has passed since the last stable MX firmware update?

Here to help

Almost a year has passed since the last stable MX firmware update?

It has been almost a year since the last stable MX firmware update was released, MX 12.24, released Dec 22, 2016.


Do we really consider a Meraki firewall to be 'secure' when it is updated this infrequently?

Nobody with any sense is going to put a beta release into production if this is what Meraki is expecting its customers to do.


Separately Meraki firewalls, out of all the hardware they do, are probably the devices most lacking in functionality. You would have thought that they'd prioritise development for them a bit more than they are.



16 Replies 16
Kind of a big deal

I don't think Meraki uses the "beta" term in the traditional sense anymore. It's more like "early access". I compare this to Gmail in the past which was in "perpetual beta" and showed as such on the logo. People complained for years about this so they removed the beta note but still develop it in the same fashion. 


I don't buy that at all.

Kind of a big deal

I feel the same way.  When I talk to support they told me the release candidate is basically a stable release but we have a practice of only implementing the stable releases so I feel like we are pretty behind on the latest potential security releases. 

If this was helpful click the Kudo button below
If my reply solved your issue, please mark it as a solution.
Kind of a big deal
Kind of a big deal

This is the firmware release process:


This is the bit you would be interested in:


A stable release candidate matures into a stable version over time as it is slowly rolled out to devices globally. After 20%+ of devices are running the stable release candidate, a final formal review is conducted on the firmware. Again the same KPIs are analyzed as used in the stable release candidate review. Upon completion of these processes the firmware can be promoted to "Stable". After promotion, stable versions can be applied by any customer via the firmware upgrade tool on dashboard. The latest stable version is also the version that is used for all newly created dashboard networks for a particular device. 



I'm not saying I agree, so don't shoot the messenger, but that is the process.

They defiantly need to re evaluate this process.

This article is very helpful

Here to help

Here is yet another thread discussing this very issue:


Can we have a statement from Meraki please?

When can we expected a new stable firmware release for the MX series?

Almost a year between releases is utterly ridiculous.

Kind of a big deal

@Squuiid There is a stable release candidate available right now. 


So, basically the current stable release does not include the following security fixes.
How is this product even considered a viable firewall?!

The practice of not updating your stable branch with security updates for almost a year is ludicrous.


Security fixes:

So, basically the current stable release does not include any of the 176 CVE security fixes from the release candidate.
How is this product even considered a viable firewall?!

The practice of not updating your stable branch with security updates for almost a year is ludicrous.


Where is the meraki reply to this? The current products are vulnerable. An explanation is required.

Kind of a big deal

Not formally announced but looks like we have a 12.26 now.  


Bug fixes
  • Fixed a case where WMI login events were not updated
  • Corrected an issue where active FTP flows would fail when routed through the MX
Security fixes
  • CVE-2015-3138
  • CVE-2017-11108
  • CVE-2017-11541
  • CVE-2017-11542
  • CVE-2017-11543
  • CVE-2017-12893
  • CVE-2017-12894
  • CVE-2017-12895
  • CVE-2017-12896
  • CVE-2017-12897
  • CVE-2017-12898
  • CVE-2017-12899
  • CVE-2017-12900
  • CVE-2017-12901
  • CVE-2017-12902
  • CVE-2017-12985
  • CVE-2017-12986
  • CVE-2017-12987
  • CVE-2017-12988
  • CVE-2017-12989
  • CVE-2017-12990
  • CVE-2017-12991
  • CVE-2017-12992
  • CVE-2017-12993
  • CVE-2017-12994
  • CVE-2017-12995
  • CVE-2017-12996
  • CVE-2017-12997
  • CVE-2017-12998
  • CVE-2017-12999
  • CVE-2017-13000
  • CVE-2017-13001
  • CVE-2017-13002
  • CVE-2017-13003
  • CVE-2017-13004
  • CVE-2017-13005
  • CVE-2017-13006
  • CVE-2017-13007
  • CVE-2017-13008
  • CVE-2017-13009
  • CVE-2017-13010
  • CVE-2017-13011
  • CVE-2017-13012
  • CVE-2017-13013
  • CVE-2017-13014
  • CVE-2017-13015
  • CVE-2017-13016
  • CVE-2017-13017
  • CVE-2017-13018
  • CVE-2017-13019
  • CVE-2017-13020
  • CVE-2017-13021
  • CVE-2017-13022
  • CVE-2017-13023
  • CVE-2017-13024
  • CVE-2017-13025
  • CVE-2017-13026
  • CVE-2017-13027
  • CVE-2017-13028
  • CVE-2017-13029
  • CVE-2017-13030
  • CVE-2017-13031
  • CVE-2017-13032
  • CVE-2017-13033
  • CVE-2017-13034
  • CVE-2017-13035
  • CVE-2017-13036
  • CVE-2017-13037
  • CVE-2017-13038
  • CVE-2017-13039
  • CVE-2017-13040
  • CVE-2017-13041
  • CVE-2017-13042
  • CVE-2017-13043
  • CVE-2017-13044
  • CVE-2017-13045
  • CVE-2017-13046
  • CVE-2017-13047
  • CVE-2017-13048
  • CVE-2017-13049
  • CVE-2017-13050
  • CVE-2017-13051
  • CVE-2017-13052
  • CVE-2017-13053
  • CVE-2017-13054
  • CVE-2017-13055
  • CVE-2017-13687
  • CVE-2017-13688
  • CVE-2017-13689
  • CVE-2017-13690
  • CVE-2017-13725
  • CVE-2016-9840
  • CVE-2016-9841
  • CVE-2016-9842
  • CVE-2016-9843
  • CVE-2016-5131
  • CVE-2017-3135
  • CVE-2017-3136
  • CVE-2017-3137
  • CVE-2017-3138
  • CVE-2016-10087
  • CVE-2016-2217
  • CVE-2016-8864
  • CVE-2016-2776
  • CVE-2016-2775
  • CVE-2016-8615
  • CVE-2016-8616
  • CVE-2016-8617
  • CVE-2016-8618
  • CVE-2016-8619
  • CVE-2016-8620
  • CVE-2016-8621
  • CVE-2016-8622
  • CVE-2016-8623
  • CVE-2016-8624
  • CVE-2016-8625
  • CVE-2016-6304
  • CVE-2016-6306
  • CVE-2016-6303
  • CVE-2016-6302
  • CVE-2016-2179
  • CVE-2016-2181
  • CVE-2016-2182
  • CVE-2016-2180
  • CVE-2016-2178
  • CVE-2016-2177
  • CVE-2015-8899
  • CVE-2017-3731
  • CVE-2017-3732
  • CVE-2016-7055
  • CVE-2016-10002
  • CVE-2016-10003
  • CVE-2016-9131
  • CVE-2016-9147
  • CVE-2016-9444
  • CVE-2016-7922
  • CVE-2016-7923
  • CVE-2016-7924
  • CVE-2016-7925
  • CVE-2016-7926
  • CVE-2016-7927
  • CVE-2016-7928
  • CVE-2016-7929
  • CVE-2016-7930
  • CVE-2016-7931
  • CVE-2016-7932
  • CVE-2016-7933
  • CVE-2016-7934
  • CVE-2016-7935
  • CVE-2016-7936
  • CVE-2016-7937
  • CVE-2016-7938
  • CVE-2016-7939
  • CVE-2016-7940
  • CVE-2016-7973
  • CVE-2016-7974
  • CVE-2016-7975
  • CVE-2016-7983
  • CVE-2016-7984
  • CVE-2016-7985
  • CVE-2016-7986
  • CVE-2016-7992
  • CVE-2016-7993
  • CVE-2016-8574
  • CVE-2016-8575
  • CVE-2017-5202
  • CVE-2017-5203
  • CVE-2017-5204
  • CVE-2017-5205
  • CVE-2017-5341
  • CVE-2017-5342
  • CVE-2017-5482
  • CVE-2017-5483
  • CVE-2017-5484
  • CVE-2017-5485
  • CVE-2017-5486
  • CVE-2016-10229
Known issues
  • When content filtering is enabled, in some cases websites may be erroneously blocked if the IP address they are hosted on has been previously associated with malicious behavior. This is an issue for CDNs and server farms that host many web resources from a single IP address. This is resolved in MX 13.3.
  • Networks with many flows may experience increased latency every 60 second seconds. This is resolved in MX 13.3.
  • In a rare case, MX64W and MX65W platforms may induce notable delay to network traffic. This is resolved in MX 13.4.
  • Google Safesearch and Restricted YouTube content are only available using a deprecated implementation. This is resolved in MX 13.6.
  • During device boot up, an MX operating as a one-armed VPN concentrator may map received AutoVPN and Teleworker VPN flows to an incorrect flow state. This will prevent tunnels from being established using that flow. This issue does not occur after the one-armed concentrator has fully booted. This is resolved in MX 13.8.
  • HTTP file downloads that have the content_encoding flag set will allow subsequent downloads on the same HTTP connection to bypass Advanced Malware Protection (AMP) inspection. This is resolved in MX 13.9.
  • In some cases, MX84 appliances will not forward BPDU messages appropriately during device boot. This can result in an incorrect downstream spanning tree topology. This is resolved in MX 13.9.
  • MX appliances with AMP enabled may become unexpectedly unable to communicate with the AMP cloud. When this occurs, the MX will drop files that a disposition cannot be obtained for. The majority of these occurrences are resolved in MX 13.12.
  • In very rare cases MX65 and MX65W platforms stop forwarding inter-VLAN, WAN, and VPN destined traffic until a device reboot is performed. This is partially resolved in MX 13.9 and fully resolved in MX 13.12.
  • In rare cases, whitelisted URL patterns can still be blocked by content filtering. This is resolved in MX 13.18.
  • On networks with a very large number of flows, MX appliances may induce packet loss in 15-minute intervals. This is resolved in MX 13.19.
If this was helpful click the Kudo button below
If my reply solved your issue, please mark it as a solution.
Comes here often

OK 12.26 is out now and we update our Network at last weekend. With the new release reboot the MX100 2 times a day. I think we switch back to 12.24 and hope the best for further releases.



Kind of a big deal

I've done 12.26 on two of our MX100's and no reboot issue so far (been a few days).

If this was helpful click the Kudo button below
If my reply solved your issue, please mark it as a solution.
Comes here often

Hello, it looks like the reboots are related to connection attempts of the client VPN. Do you use Client VPN?

Kind of a big deal

We don't but that is certainly interesting to know and I'm sure other members here could benefit from that fact. 

If this was helpful click the Kudo button below
If my reply solved your issue, please mark it as a solution.
Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.