Please Upgrade to Immediately for Security Fix: Firmware for UCM6202/6204/6208/6510 Released as Official



Dear Grandstream Customers,

Firmware for UCM6202/6204/6208/6510 is now released as official. The firmware and release notes can be downloaded from:

Firmware has added security fix and it’s recommended to upgrade to immediately. Here is the security bulletin:

After upgrading, please make sure to change web access passwords for ALL users in UCM web UI->Maintenance->User Management page, which includes super admin, admin and consumer users. It’s also highly recommended to change the username to be different from the previous username. If any unknown user exists in User Management page, please remove it immediately.

Please contact us should you have any issues. Thank you for your support for Grandstream products.

Technical Support
Grandstream Networks, Inc.




After updating to, after the reboot, on several UCM’s I got an error on the first login attempt. “Too many login failures, please try again in 24 minutes”. I’m not 100% the exact wording of the error but, I don’t have fail2ban setup for that time frame. On some devices, I have it set much longer, on other devices, it’s shorter. But nothing is set to 24 ish minutes.

On no device, did I get a fail2ban email from the phone system as I normally would have.

I started to click the reboot button then close the browser. Wait for a couple minutes then reopen the browser and try to log in. That seems to have helped. All instances with troubles happened in Chrome but, that could just be a coincidence.


Thanks for this note. BTW, do you have any peered systems running the new firmware? I have stayed at .19 as the .20 broke all my LDAP between my peered systems. Having seen nothing but complaints about .20 I have been somewhat loathe to move.


I do have a couple of peered systems but, stopped using BLF’s back in 15.xx because it’s just crap. I’d tell you the problems I’ve had but I’d just get mad and stressed again. Perhaps @drostoker has some comments. I know he’s got a couple peered systems too.

Seriously, my heart is pounding now just thinking about the crap I went through. So. It all started on a lovely winters evening. Then it all became crap, utter garbage. It was one of those one way updates. New database or something.

I performed a standard upgrade on two interconnected systems after waiting a couple of weeks and checking feedback on the forum. After the update, all at once, phones where no longer programmed correctly, something changed in the peered trunk (I don’t recall) and the BLF’s stopped working. Perhaps I shouldn’t have but, I did the upgrades remotely.

From my perspective, everything looked like it had gone well. Other systems to update, moving on.

First call came in at 7:00 am, after staying up late updating systems, this was early for me and I take ownership that I should have controlled the whole process better. I was tired.

Regardless. I spent all day on the phone with GS, with two or three reps. We worked out the trunks right away so, at least calls were routing between the two offices.

I should also say, I’d only sold a couple of system as this time and was very inexperienced.

Still had to figure out why the phone programing was borked and the BLF’s were not working.

Finally figured out that the pcodes I programmed where moved down by 1 in zero config. So, my first pcode was correct. Somehow my second pcode was blank. my third pcode had the second pcode value and so on.

Fix the template and push to phone. They are now working without BLF.

I know I’m rushing through this but, with packet captures and screen sharing with GS, it was end of day for them. They told me to factory reset both systems and rebuild by hand and that they were closing the ticket.

Factory resetting them at this point was no longer an option as the two offices had closed. I worked on the systems all through the next night and part of the next day.

Call GS back and they wouldn’t speak to me until the systems had been factory reset.

So, the customers limped along for a couple days until the weekend when I went in, armed with a bunch of screenshots and what not, and factory reset the two systems. Everything worked except the BLF’s. GS said that using the new backup files, they were able to reproduce the problem and it should be fixed in the next firmware update. a couple of months later, the customer insisted I buy back all the side cars which were basically useless now, which I did. Managed to sell them on ebay as used for more that I paid so, not a total loss.

That was almost the last time I dealt with GS. But I know from my days as tech support that sometimes the company is not represented by the front end staff. So I chatted with @lstutesman @drostoker and others and was encouraged.

To date, I have not attempted to interconnect UCM’s as I’ve become convinced it’s not stable. Which is why I referred you to @drostoker who’s had better experience and probably does not share my emotion based bias.

My largest system, which required BLF’s to work stable at 14 sites across North America, is hosted in an onsite data center with fiber and a solid wisp backup providing service. Great UPS that was preexisting for other IT infrastructure. Two 6510’s with HA, that system works great. I’d much rather focus on one reliable location and connect the other offices in to the main system. But I digress.

Also, no other systems I updated that evening had issues. Just the interconnected one.


Hi Robert.

Sorry, I am at the beginning of my upgrade journey above .19 so I have nothing to share at this point.

But to add to @costwisewpg’s comments above, I have not had issues with remote BLFs any more than I have had with local ones. [Ihope I am not speaking to soon!]


Whew! I can feel your “stress” on this one!

My current peered boxes are working fine for the most part. The Eventlist BLF lights up the sidecars on our 2 2170’s (one in each big location) just fine and LDAP phone books work fine. I did try to upgrade when .20 came out and it just broke so many things that I moved back to .19. I ended up with three UCM’s as it sounded like I would have unending issues with Zero Config across my VPN’s, this was a big change form my original single centrally located FusionPBX box. We really wanted the ZC capability as Fusion required touching a phone before it could pick up provisioning so 3 UCM’s it was.

I would like to upgrade at some point, one of the reasons for going with the UCM’s was to make sure there actually was honest-to-God support available if things went sideways (Fusion was iffy in that regard). We also wanted something that was easy to upgrade and it seemed like the UCM’s ticked all those boxes. But my upgrade experience with them has not been all that great to this point in time. Honestly, knowing what I know now, I might have gone a different route but I am “here” so I have to make the best of it.

Maybe David can jump in on this convo in terms of the peered stuff. @drostoker, any comemnts?


Just saw this note, David. Thanks for jumping in. If you get a chance to play with peered on .20 please update me. I have a spare box that I can try .20 on and see what happens, just can;t peer it easily at this point without messing with some firewall bits.


No problem. I have .20 on my own UCM (just upgraded to .23) as well as .20 on a couple of systems. None of them peered mind you, but I have been lucky I guess as I have not had problems with them.

I will be doing upgrades to .23 across the board as/when clients make the upgrade decision.


Thanks. If I can a VPN sorted to the house I will bring up the spare on .23 and see what happens.


I understand your discomfort but I invite you not to give up, know that every competitor brand, every competitor’s product, every product comes with good things and bad things, I have tried in my 36 years of experience many products and many manufacturers, I have never found a single product working and 100% reliable.
Then you have to divide between problems created by the machine (for sw problems, manufacturing problems etc…) and problems “created” by the installer.
I get up in the morning and say to myself “I have to learn”, when you are convinced that you have finished learning, it is time that you are doing everything wrong.
So I invite you to “get up” and try to understand better where the problem is and solve it, I help you as much as I can help you, as I do with all those who ask for help here.
Often I’m the one asking for help, and it’s not a problem for me, a hug,

I hope the translation is true to what I want to communicate.


I cannot limit access ip to WEB UI ACCESS UCM, another problem why i block all ip connected to ip wan but i can still connect to it?

i use firmware


First of all, you have to apply the rules to an external firewall, let UCM do the job of UCM Server, and that’s a tip.
Second, the rule you created might not be correct, might not be in the correct order (so don’t read it) etc…
Third, you should open a ticket if you don’t get an answer here.


Thanks for the reply. I think I don’t know where is wrong. I allow the ip to be connect first then drop all ip.
I created a ticket but no answer yet


Saturday and Sunday you work?

I think it’s faster to handle everything from the external firewall, good job.


yes I have shifts on Saturday


Helpdesk Monday to Friday


We lost money with this SQL injection vulnerability.
Nothing is perfect but i have some questions.
I added my ip to Fail2ban whitelist, but it still goes to banned list if i use more attempts. This problem also happenes when i use from 1 ip several accounts to access the web interface in incognito mode.
Is it possible to warn UCM customers about critical updates wia device or plan auto updates?
Also CDR users can delete records, can you make read only rule for CDR?


you have to make requests via Ticket


What mode is the UCM running with regard to the network, - dual, route or switch?