anilakar
Joined 10 years ago
Joined 10 years ago
In other words, you are the supply chain. You're responsible for the bugs you create, but at least they are your bugs not caused by upstream's upstream's upstream's maintainer installing an infected JS library.
Shall we call this "vertically-integrated programming" then? :-)
The article is dated August 2026. Synacktiv (a different company) reported the very same vulnerability for older system managers/controllers already in 2023. Their report[1] says Danfoss told the products are EOL and should be upgraded. At no point did Danfoss fix the same issue in 800A. Typical.
Back in 2016 when we were integrating their 850 series system managers we encountered an issue with the HTTP API returning 400 series errors over slow links. We sent them PoC code written in Python 3. One month later they sent us an email, complaining that they first had to backport the PoC code to Python 2.7 as that was the newest version they could install. They also attached a "fixed" PoC code snipped where they had removed the artificial delays that did not trigger the issue. Danfoss never did anything to actively fix the issue.
One year later I browsed changelogs for the commercial RTOS that Danfoss used and realized the issue was fixed upstream in 2010 or 2011. That means their AK-SM 850 had at least six years worth of unfixed bugs.
[1] https://www.synacktiv.com/sites/default/files/2023-10/synack... (despite saying SM800, the firmware in question is for AK-SM 850)
Edit: The parent commenter seems to work at Danfoss on their Leanheat platform.
Every now and then our customers ask if we can add remote control for specific parameters but we've always turned them down, citing liability reasons.
Re: legacy Danfoss systems such as AKM, 720 and 850 there is no way to have read-only access (for different reasons in each case). I haven't been able to find weaknesses in the new 800A yet, but that's only because I have not had to try yet.
Danfoss AK-SM 720 or 850? Pull the ethernet cord, now.
The latter can be flashed with the new 800A series firmware which is safer, but I still would not put it on the public internet under any circumstances.
Sigh. It's OpenID (the original one) all over again? Everyone wants to be the auth provider, nobody wants to accept other auth providers.
OS-specific abstractions should not leak to web apps under any circumstances.
I would only recommend using it instead of the standard Arduino Processing IDE.
Sigh.
Write a C or C++ API that works with pointers. Make it handle null pointers and errors elegantly so that the API user can safely chain calls and only check the final result. Claude decides it's better to be safe than sorry and peppers its code with intermediate nullptr and return value checks anyway.