PHP vulnerability and mikrotik services

Oh, my bad. I thought it was run by Mikrotik and official.

mikrotik.com footer has official social media, but we do not always post official announcements there. we do not have instagram etc.

Only this two (except obviously TikTube and Youtube)

https://facebook.com/mikrotik
are from official MikroTik

It's strange that it's a general belief that social media driven mostly by private companies are the "official medium" for everyone.
Even Goverments use them to make statements which are considered "official" but they are not.

From time to time, when owners of these media change their mind how to deal with information on their websites, many users get shocked that their data could be removed, changed or manipulated without their acceptance, so then a loud rumpus start but "owners" do not care as they got what they wanted.

Your own, selfmanaged place, is the best placefor an official information.

Thank goodness there’s still someone with a functioning brain in their head...

Play ball man, play ball... we’re all on the same (official) channel here :wink:

Correct. But y'all do decide defaults like auto-update=no. I'd imagine the upstream container images will be patched... but using current defaults it requires manual intervention to update them. Especially given the pace of vulnerabilities found. No need to hand users a gun without a safety.

Now the new Matter/Threads container boarders on "part of RouterOS" since Matter support comes from a container MikroTik recommends and docs suggest. It doesn't have PHP, AFAIK, so not at here, but...

What MikroTik devices do you own and how were they affected by the downtime exactly?

I think the whole idea was a more informinal information as to why the MT website was down.

MT did manage to put up a page quickly but could have provide more information like ONLY the web site is down and all other services are up and running and maybe a link to the forum.

Contingency plan?

https://www.youtube.com/watch?v=_B7MzBmjaJ8

What other services, for instance, require the website to be online?
(besides the one for exams, which probably wouldn't have even crossed your mind if I hadn't mentioned it)

Disconnection anxiety is an illness.

The emergency downtime was a wise and forward-thinking move.
When you have a serious problem to solve, you don’t have time to waste on frills.

If I’m out fixing a radio link damaged by a storm, and a client calls me directly (assuming they even manage to get through) I tell them to get lost.
The automated phone system already states that we’re carrying out repairs and that the issue will be resolved as soon as possible.
If you pester me, you’re just wasting my time and delaying the repair.

@rextended

If the was directed to me. That's not what I'm getting at. MT could have done a better job with the temporary down page. That's all.

I agree that taking it down was the right move. I'm sure that MT has a team of people that could have made updates on the temporary web page.

Contingency plan?

https://www.youtube.com/watch?v=_B7MzBmjaJ8

Just making light of it. LOL

No, it’s directed more generally at those who suggested that a different page could have been created.


How could I have gone about recording a better voice message on PBX,
calculating response times,
providing a precise estimate of when service would be restored to that area,
and so on...
when all that time spent doing so would only have delayed the actual resolution?

They should consider themselves lucky to get the "Site in maintenance" note. The University I currently work for chose to just firewall affected sites outright - zero response - while we plowed through the mess.

Bro, all other sites I checked, presented only a timeout. No message, only the standard browser timeout page. MT was one of only a few who wrote a message (I assume in the vHost of their reverse-proxy). Ok, they could have made a link to the forum there, but at least not the timeout-page.

So, plz stop crying like a big baby about "MT could have done a better job", MR. PERFECT :melting_face: PHP could also have done a better job by simply not making such a big, fat, ass error - twice - and dont patch it in over 20 years...

Blame AI.

Everything has bugs. Now the current rate they are found and fixed (or potential exploited) is moving quicker than anyones existing processes were designed... that ain't an MikroTik specific problem.

For the record, I don't think MikroTik did anything wrong here. They are merely a user PHP, and RouterOS minimal design/userland certainly has no PHP, so it's unaffected. So it ain't material for the security blog. Here, MikroTik followed industry best practices, which be responding to urgent security alerts and remediating quickly.

Now could they have had their load balancer put up some "Down for Patching" message, perhaps. Or, perhaps just have some script that post to various social media account they do own, so send a notice to all "channels". While I'm not a regular on X/Facebook/etc..., it makes sense to give "Heads up" on them for more social folks.

On "Blame AI", perhaps. But AI could also write a quick script for MikroTik to post to the various MikroTik owned accounts, and/or update some static landing page when one of there services is down... @normis' Hermes could even have a SKILL.md for this :wink:

Yep, essentially the usual nothinburger as I see it, still ...:
https://www.cve.org/CVERecord?id=CVE-2026-89035

My simple "Blame AI" was with an invisible :wink:

Because that was a very unfair statement.

Well @normis was talking about shell2php in his top post... CVE-2026-89035 is different story...

Makes me wonder about that. MT has a large block of ip addresses. Where are the backup servers?

No services should ever go down with MT having a large block of ip addresses.

Contingency plan?