Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2022-2289PUBLISHED: 2022-07-03Use After Free in GitHub repository vim/vim prior to 9.0.
CVE-2022-2288PUBLISHED: 2022-07-03Out-of-bounds Write in GitHub repository vim/vim prior to 9.0.
CVE-2022-2290PUBLISHED: 2022-07-03Cross-site Scripting (XSS) - Reflected in GitHub repository zadam/trilium prior to 0.52.4, 0.53.1-beta.
CVE-2022-2287PUBLISHED: 2022-07-02Out-of-bounds Read in GitHub repository vim/vim prior to 9.0.
CVE-2022-34911PUBLISHED: 2022-07-02
An issue was discovered in MediaWiki before 1.35.7, 1.36.x and 1.37.x before 1.37.3, and 1.38.x before 1.38.1. XSS can occur in configurations that allow a JavaScript payload in a username. After account creation, when it sets the page title to "Welcome" followed by the username, the usern...
User Rank: Moderator
12/10/2020 | 6:12:57 PM
I don't expect this situation to change whatsoever, so I believe that the workaround is for security conscious users & organizations to assume that FOSS software is highly insecure and should only be run on untrusted PC's in untrusted network subnets. By this I mean that a computer network should be divided into isolated & firewalled subnets that are separated into high security (trusted), medium security (production), low security (untrusted) and public (totally untrusted) zones that never co-mingle their network traffic. That way security breaches in untrusted subnets are irrelevant to the organization because no valuable private information ever exists in them – they are only for public facing insecure tasks with no privacy value.
That, actually, makes sense for those of us embracing open source – why would we need data security privacy on a computer devoted to creating FOSS & FOSH content that we'll be donating to the global commons anyway? Sure, we might take basic security precautions, but nothing beyond that is worth our time & effort. Especially if the FOSS we're using is full of unpatched security holes anyway...