Our security team informed me about CVE-2025-10948 which seems to be a RCE, but I'm missing details. The most critical one "needs the actor to be authenticated before using the attack or is it pre authentication"?
Has anyone details?
https://euvd.enisa.europa.eu/vulnerability/CVE-2025-10948
https://nvd.nist.gov/vuln/detail/CVE-2025-10948
Looking at the text at
which would mean that it is pre authentication.
It would be nice if these "researchers" followed responsible disclosure guidelines and contacted the vendor before publishing. No emails, no nothing. We are looking into this.
Strange, as this line was noted in the CVE........
The vendor was contacted early about this disclosure but did not respond in any way.
You see Normis, if such 'researchers' had to go through a sandbox process where they learned the basics of how to report and release CVEs, and had their announcement approved before going live this would have gone far smoother. 
It seems that by "basic authentication" it is meant, KNOWN username (aka "admin")+blank password.
So it shouldn't affect anyone that changed "admin" as username.
" Remote Exploitation: Can be triggered via HTTP POST requests with malicious JSON payloads"
Well, in the default firewall remote access to the HTTP(S) port is not allowed.
I have a disabled "admin" user. Still I was able to kill the http process of my router using the malicious request. I guess the payload is parsed before authentication. I had the system/resource/print open while I executed curl. I saw a RAM drop and disk space going down. In the end it even occupied all of my disk space. It was 100kib and after a reboot it is 0. The JSON parser seems to really have left some hidden files after crashing. I think it now needs a netinstall to get rid of the junk.
But then why the curl command line has "-u admin:" :
curl -k -u admin: -X POST http://x.x.x.x/rest/ip/address/print \
--data '{"0":"\u0\0\\"0' \
-H "content-type: application/json"
?
Does this mean that disabling admin is not enough or that the curl command is unneededly using the -u flag?
well, i tried the curl in steps. first i tried bare minimum only the url. then adding arguments. and the API response was always "unauthorized". only finally to add the malformed JSON payload - it gave EOL. It maybe even works by using "-u foobar:".
Yep, but the real world impact of this thing would go from 0% to 100%.
If it works with (percentages just invented):
-u foobar: 100%
-u admin: 60% (admin enabled)
-u admin: 40% (admin disabled)
-u admin: 0% (admin deleted)
Justed tested. -u foobar: made it crash as well. It never existed a user named "foobar".
Then It Is more serious than I thought, and It means there are two distinct issues:
Of the two, the first Is apparently the "worse" one as It Is the one crashing the RouterOs, but the second Is actually "terrifying", It should mean that data Is received (and parsed or mis-parsed) without any authentication.
I can confirm it doesn't matter what user you specify, running that curl command crashes the http process on the router and causes the creation of autosupout.rif. The http service seems to restart immediately and so far I haven't been able to exhaust memory or disk space of my hAP ax2 yet.
I presume MikroTik is working on fix to the crash-on-parsing part. But agree with @jaclaz RouterOS probably should not be parsing JSON until authentication completes successfully.
But this begs several questions:
Regardless of whether responsible disclosure was practiced or not, it should now be at least noticed on https://mikrotik.com/supportsec so folks at least could disabled http and https which mitigate the immediate DoS risk (at the expense of REST and webfig and others). But security through obscurity is even a worse plan once there is a public CVE.
Is the libjson.so MikroTik developed code, or is it open-source? If it's the later, it's not been disclosed on EULA nor in MikroTik GPL disclosure. Additionally, if it is some OSS code, the "libjson" library author should be contacted, since it might not just be RouterOS affected.
It be good if MikroTik and/or reporter got to bottom of how the report either got lost, or if the author even tried. MikroTik's security page suggests When contacting MikroTik about vulnerabilities, please use the e-mail address security@mikrotik.com so perhaps the OP used the normal support@mikrotik.com which may not have same priority. But one suggestion be that "Security Issue" be a category on the [JIRA] support portal page to perhaps help ensure they get timely reviewed.
Affected Systems
To be clear what is affected and what to do - disable http/https management ports on unsafe and public networks.
Most of the web standards are so convoluted and in so many layers that it's really easy to find bugs like this - and actually with this particular thing (\u in json) libjson is not only one that had such a problem.
Not exposing the http (or https or api) to anything is probably the safe route. If one doesn't want to go with elaborate vpns, there's ssh local port forwarding.
I have to add: My requests were using https. I have disable http service by default. In my case there was no autosupout.rif generated, and http service crashes and does not come up again. One malicious request - end.
I think this is not related to JSON or web standards. This is a typical issue in any programming language - improper input handling. Seems like a classic: parser unaware of unicode chars. Always a surprise - even in 2025.
You can view it that way, and you're not absolutely wrong. Out of bounds access is kind of the typical buffer overflow problem that memory-safe languages mostly solve.
Where however I am in massive disagreement is that it is also very much a JSON design failure. JSON designers wanted so much to stick to JavaScript-style syntax that they allowed C-style escaping to happen inside strings, which I think is a major blunder. In you actually want to represent unicode characters in a string, then a unicode format such as utf-8 (which by the way is also prescribed for JSON) should be used. The onyl thing that really needs to be escaped is the double-quote character itself. If you really want to insist, maybe some others such as "\0".
I always had this major beef with JSON: that you can't actually encode arbitrary things in them. Neither can you encode arbitrary utf-8 in any sort of sane manner, nor any other sort of binary buffer. (When something is known to be purely binary, often a base64 version is encoded as a string as a workaround.)
If you want to look at a sensible implementation for these things you don't have to look further than BSON, which handles both strings and blobs efficiently and without guessing games on the part of the parser. (BSON (Binary JSON): Specification) By the way, BSON is not some unknown things, MongoDB for example actually stores, parses and returns it, and many companies' internal APIs receive and emit application/bson instead of application/json.
The adoption of JSON forces the programmers to deal with parsing unicode, which would not be a terrible burden, but embedded systems that have no space for the usual massive unicode libraries have to implement "something" that can half-parse unicode, because JSON parsing relies on it. These libraries are not widely available, maintaind and reviewed. (You can sort of guess that I'm writing this from experience.)
That these embedded systems are basically forced to accept JSON input for connectivity with everything from NodeRED toa web browser front-end actually forces these sorts of errors.
This absolutely has a lot of relation to the fact that web standards are "turtles all the way down" - let's assume we can parse unicode, then JSON, then that we can validate these safely, then that whatever object hierarchy results from this we can always allocate in memory, etc. Even something as simple as interpreting the "Origin:" header for CORS validation is so convoluted that one of the lead developers on curl got into a public argument on how the name should be canonicalized for purposes of comparison.
Frankly, I don't believe that it's possible to design a small embedded web server that obeys today's standards and can't be exploited in a hundred different ways. Yes, reading past the buffer is an especially grave error, but probably there are many more where this came from.
Just to clarify a bit further: this is not a case of not expecting unicode, but the mishandling of a malformed escaping particular to json, the extended "\uXXXX" form to be exact. (The standard for which was repeatedly revised.)