You should never have used any closed source wallet-- but being open source is not enough.
In this case the rng was replaced with an obviously broken toy and no one noticed because the project has no reviewers.
Some extra relevant links:
https://github.com/libbitcoin/libbitcoin-system/pull/559The pull request adding the vulnerability, the lack of review or collaboration is worth noticing. The prior code was already dubious in that AFAIK std::random_device library doesn't promise that the randomness is suitable for cryptography. I believe on common systems where this code was run the old code was not likely to be exploitable, but I wouldn't bet my money on it.
https://twitter.com/evoskuil/status/1688657656620167169Developer commentary on this issue. I can't figure out what "long-documented intended usage" a seed command that mandates 128-bits of output but never has more than 32-bits of entropy would have.
https://archive.is/A7Jn6The documentation the tweet references. I don't know how the 'Pseudorandom seeding' warning there would be distinguishable from warnings against CSPRNGs in favor of dice rolls or whatever, perhaps this is an example of the harm that chicken-little crying about CSPRNGS causes. Nor can I figure out for whose convenience this function would serve except attackers. In any case, this is the only place I found any kind of warning and the warning postdates the mastering bitcoin usage (as well as the change that made the command unconditionally unsafe).
https://archive.is/HDe8hCurrent libbitcoin-explorer instructions telling users to use the seed command to generate private keys.
https://archive.is/fhm5J#selection-12915.2-12915.10Current libbitcoin-explorer instructions telling users to use the seed command to generate BIP39 seeds (also private keys).
https://archive.is/PWLKJCurrent libbitcoin-explorer documentation on randomness noting that bx seed is the ONLY source of randomness available to users in the package, and that all other commands that need randomness require the user to provide it. It also notes that 'bx seed' will not function if less than 128-bits are requested.
The private key and bip39 seed usage (above) sure appears to be the "intended usage" in their documentation, but the "bx seed" function as currently implemented (since 2016) is unambiguously not fit for those purpose.