TheStreet posted some numerology and stock analyst mystical mumbo jumbo before outlining this bottom line for Tesla investors, a true buried lede if I ever saw one.
“The [Tesla stock] is oversold for the first time in almost a year,” wrote long-time technical analyst Jason Meshnick in a post on TheStreet Pro.” …of course, oversold never means buy. Stocks can remain oversold longer than you or I (or even Musk) can remain solvent,” said Meshnick. […] “More than a dip below about $250, and I’d sell as fast as a Model S Plaid,” concluded Meshnick.
It’s a garbage company making garbage that nobody should want.
“Invest? This isn’t hard to figure out for those based in reality instead of Wall Street nobs who transform tragic deaths into yacht funding for trust fund kids like Donald Trump being raised cruising the French Riviera with dreams of someday colonizing Gaza.
Who’s still investing in Elon Musk? Russian money launderers and institutional investors who somehow missed the Madoff lesson—that financial houses of cards collapse spectacularly fast. For everyone else, Tesla stock isn’t an investment opportunity; it’s a catastrophic dumpster fire to avoid entirely, best viewed from a country where people are definitely not buying any more Tesla.
Wealthy Chinese investors are quietly funnelling tens of millions of dollars into private companies controlled by Elon Musk using an arrangement that shields their identities from public view, according to asset managers and investors involved in the transactions.
Espressif has 35 documented security and bug advisories since 2020, ranging from genuine security flaws to end-of-life announcements. Yet their newest entry, a plain new CVE-2025-27840 out of Spain regarding an ESP32 chip, stands out not for its discovery but for its alarmist classification.
To be clear, this is just the latest security advisory in Espressif’s catalog, following a dozen in 2024 and fun ones like “Bypassing Secure Boot and Flash Encryption using CPA and FI attack” (AR2023-007) and “Security Advisory for WLAN FragAttacks” (AR2023-008).
That’s why, looking at the ESP32, I say we shouldn’t be surprised if a kid driving an industrial harvester has found something to chew on in the exact same field that for the last five years has produced a whole lot of delicious potatoes.
“Mom, Dad! My research discovered food! Call the news!”
When researchers Miguel Tarascó Acuña and Antonio Vázquez Blanco announced their findings at RootedCON in Madrid, they used the term “backdoor” for an ESP32 Bluetooth implementation.
However, where the prior litany of vulnerability reports represented actual attack vectors with demonstrable exploitation paths, their claim comes up short by comparison. It deserves a rebuff through some rational technical dissection that uses a baseline to verify backdoor claims.
Examining their actual discovery reveals something rather mundane in the security vulnerability hierarchy: undocumented vendor commands residing precisely where the Bluetooth specification expects vendor commands to exist—in OGF (Opcode Group Field) 0x3F.
We should be fair to prior researchers, not to mention Espressif’s track record of proper vulnerability disclosure. Applying a consistent technical rigor of research to the new CVE greatly waters down claims being made. It simply doesn’t hold a candle to actual hairy security like a June 2021 (AR2021-002) flash encryption flaw.
Be honest now, are you scared more because I said encryption flaw, or because you’re seeing Chinese?
An undocumented command set of course could sound very, very scary to an untrained ear, to those who don’t read command sets and thus can’t understand what’s going on. So let’s dive in deep to apply some banal vulnerability taxonomy and see what commands actually were discovered versus what was waved on the plains of Spain like a big red cape to work up some bulls….
I guess we can call this doing research on the research, or even some peer review if you must, given disclosure of vendor-specific HCI (Host Controller Interface) commands. I will try here to make a significant technical distinction, with important security implications, to explain why a backdoor doesn’t seem to exist.
The researchers cleverly reverse-engineered the ESP32 firmware by analyzing multiple binary libraries provided by Espressif:
`libbtdm_app.a`
`libbttestmode.a`
`libphy.a`
`librftest.a`
`librtc.a`
Through static analysis with the NSA’s Ghidra (VROOM VROOM, push the big GO button), they discovered the ESP32 contains tables of HCI commands, with the last entry referencing OGF 0x3F—a range reserved for proprietary vendor commands.
This revealed 29 undocumented commands for low-level functionality.
Now for some bad news. A backdoor, by definition, implies some specific stuff. Any of this would help:
Intentional implementation for unauthorized access
Remote exploitability without prior access
Bypass of authentication mechanisms
The discovered ESP32 functionality however fails all three criteria:
Implementation Intent
I see proprietary debugging/manufacturing commands. The commands exist in the OGF 0x3F range explicitly designated for vendor-specific functionality in the Bluetooth specification. This is standard practice in hardware and software, across chipsets.
Access Vector
Exploitation requires sending HCI commands to the ESP32, which necessitates either having physical access to the device’s USB/UART interfaces, or a prior compromise allowing direct communication with the Bluetooth controller. Root access is needed to send arbitrary HCI commands.
Command Architecture
The commands use standard HCI protocol structure and are processed through the normal command handler. They aren’t hidden “backdoor” channels but rather undocumented extensions of the standard interface.
As you can see any claims of a backdoor stretch the definition beyond recognition. This is a case of documenting something missing a manual. Look at their discovered commands, which include:
0xFC01 - Read memory
0xFC02 - Write memory
0xFC32 - Set MAC address
0xFC0E - Send LMP packet
0xFC43 - Send LLCP packet
These are typical vendor testing/debugging functions found in most Bluetooth controllers. The commands are processed through usual RivieraWaves/CevaWaves RTOS command handlers—the proprietary Bluetooth stack used by ESP32.
With all the usual stuff in mind the actual security impact is limited to scenarios where an attacker has already achieved privileged access. In other words, calling this a backdoor is like entering a house somehow (front door, back door, window, whatever) and then saying “hey everyone I found a hidden closet in this bedroom, not on the floorplan”. Kinda significant difference from a backdoor event.
It’s still a hidden thing, on a proprietary chip, so let’s not forget some scenarios could manifest and maybe even matter to someone thinking broadly about risks.
OEMs, or someone intercepting chips, implementing an ESP32 could theoretically exploit these commands, but of course they already have physical access to modify firmware.
After gaining root access to a device with an ESP32, an attacker could use these commands to hide code in the controller—but again this requires some prior system wide compromise. Can’t use a hidden closet until after you get in the house somehow.
Physical access to debugging interfaces could allow firmware manipulation, just like virtually any embedded device. Nothing new here.
I guess what I’m saying is that it is fantastic to see someone put together undocumented functionality by applying “right to repair” principles. But it’s silly for them to call documentation of any of these functions a backdoor.
The security community should hold the line and classify it as CWE-912 (Hidden Functionality) rather than CWE-506 (Embedded Malicious Code).
While Espressif could document these commands for transparency (unless they want to give researchers something to busy themselves with), they seem to follow industry norms for proprietary extensions to a Bluetooth specification. It’s called proprietary for a reason.
The research is valuable to show Bluetooth security testing works, but the “backdoor” characterization is technically inaccurate and obviously misleading.
If there’s one thing for certain, Woz is an engineer and Musk is a snake-oil salesman.
It doesn’t take an engineer to explain why snake-oil can’t make anything better, only worse, but perhaps it helps.
…many Tesla owners have not liked software and UI (user interface) updates the company has implemented over time. Woz is definitely in that camp. “Every step up, where they changed things in the car, it got worse and worse and worse, and now it is just miserable for user interface,” he said. “Coming from Apple, user interface, the way you deal with technology, is the most important thing in the world to me — and Tesla is the worst in the world at that.” […] “And I’m just sick of that company, the support is so ridiculous.” […] “I’ve spoken on national TV shows about how he lied to us — about driving itself across the country by the end of 2016, and then by [the end of] 2017. And he got money from us, stole money from us…”
Worst in the world? Stole?
Ouch.
Woz calls Elon Musk’s tech the worst in the world, calls it a crime. Woz is legit. He knows tech. He’s an engineering legend. And I would say he knows a conman.
…photos seemed to be flagged for removal simply because their file included the word ”gay,” including service members with that last name and an image of the B-29 aircraft Enola Gay, which dropped the first atomic bomb on Hiroshima, Japan, during World War II.
Several photos of an Army Corps of Engineers dredging project in California were marked for deletion, apparently because a local engineer in the photo had the last name Gay. And a photo of Army Corps biologists was on the list, seemingly because it mentioned they were recording data about fish — including their weight, size, hatchery and gender.
Records of women and minorities also are to be negligently axed from American military history. Already a WWII Medal of Honor recipient apparently has been negligently axed by Hegseth, seemingly for not being white enough.
Jeff Prosperie, who was struck by the ax thrown by Hegseth during a segment on the show, alleges that the co-host “negligently attempted to throw an axe…
