FoxPro Revival Project Inherits a 20-Year-Old Security Hole

A hobby project reviving Visual FoxPro, the database language Microsoft stopped developing in 2007, drew 468 points and 253 comments on Hacker News on Sept. 22, and its own creator used the thread to confirm the runtime inherits a security flaw a former Microsoft engineer says he reported more than 20 years ago and that was never fixed.

"Visual FoxPro stopped at version 9 in 2007. A surprising amount of it is still running, in 32 bits, because rewriting a 20-year-old business app is how you lose the business," wrote the project's creator, posting to Hacker News under the username boredjohnny. The project, FoxDev Studio, reimplements the language as "the same language on a new runtime (Rust, compiled to wasm, checked against the real vfp9.exe)." Its GitHub repository, created Sept. 22, 2026, is MIT-licensed, written in Rust, and had drawn 76 stars, 4 forks and 11 open issues as of Sept. 24. The FoxScript project site says the runtime covers 1,722 elements of the Visual FoxPro 9 language reference, with 1,534 tested against real Visual FoxPro output, and runs on Windows x64 and Linux, including Ubuntu.

The bug a former Fox team engineer flagged inside Microsoft

The thread's most-upvoted technical comment came from a user identified as a former member of the team that built Fox at Microsoft. "Here's my problem with reviving FoxPro in any form: there's a huge security hole in the Database Container (DBC) design," wrote commenter mikestew. "For DBCs to be useful, they must be read/write to all users (there is no permissions scheme). DBCs have stored procedures that can run any FoxPro code, including Win32 calls made from the FoxPro runtime. The stored procedures are stored as plain text in a 'memo' field... modifications can be made using a text editor, bypassing any checks in the FoxPro runtime. FoxPro just executes what it finds in there." He added a specific origin for the claim: "Source: filed that bug over 20 years ago when I worked on the Fox team. No, it wasn't going to get fixed without rewriting large parts of how the DB engine worked."

Boredjohnny replied directly in the same thread, without disputing the finding. "FoxDev reads the DBC the same way VFP does, so today it inherits the hole exactly," he wrote. "The runtime is actually the one place it can be fixed. I would put in a hash of the stored procedure text into the built executable and refuse to run a container whose procs don't match. Adding it to the list."

Detail	What was said
Origin of the flaw	Filed by mikestew roughly 20 years ago while on Microsoft's Fox team
Mechanism	Plain-text stored procedures in a DBC memo field, editable outside the runtime
Status in FoxDev Studio	Inherited as of Sept. 22, 2026; no fix shipped
Proposed fix	Hash stored-procedure text into the built executable, boredjohnny said

Why the fix was never in the original product

Other commenters framed the flaw as an artifact of FoxPro's design rather than a bug in the ordinary sense. "Well, I had to call it something," mikestew wrote, after another user argued it was working as designed. "Most of the time, 'full access to data' doesn't necessarily mean 'run arbitrary code.' In this case, it does, which I don't think folks expect, hence 'hole.'" He added that the risk predates the internet: "It's because you have to worry about your own users first."

What boredjohnny says the project actually is

Boredjohnny said he built FoxDev Studio for a specific customer: "the customer is one of my dad's friends that has been running the same shop for 20 years, wanted bigger tables." He confirmed the project was "LLM assisted like most stuff nowadays," a disclosure that followed several commenters calling the marketing site AI-generated. Reports and a 64-bit table format are both unfinished on the project's roadmap, and builds ship unsigned as nightly pre-releases. No CVE has been filed for the DBC flaw, and the hash-check fix boredjohnny proposed had not shipped as of Sept. 24.

The episode sharpens a pattern flagged in other AI-assisted open-source releases: a tool built fast enough for Hacker News in two days can ship with problems nobody had time to check. It also lands the same week Git's own maintainers were still hedging on a breaking-change date for a 20-year-old codebase, a reminder that even patient, funded projects find backward compatibility easier to promise than to ship.