So I take it you didn't read the github link where the poster says that the CA has too many many permissions including server and client authentication? No?

So its not hyperbole.

Evidence verbatim from GH post:

However, even if this is in fact a well-intentioned bad execution of the code signature verification idea and not malicious in any way, it is still a pretty egregious security issue for the users of SBRW. For what it's worth, also consider the case wherein the private keys for the CA are stolen in some way from whomever currently has them.

I also want to note that the certificate has a highly inappropriate and unnecessarily broad list of key usage IDs included, of which I would assume that no more than two or three are necessary for the advertised function of this certificate. The complete list follows:

List Server Authentication (1.3.6.1.5.5.7.3.1) Client Authentication (1.3.6.1.5.5.7.3.2) Code Signing (1.3.6.1.5.5.7.3.3) Secure Email (1.3.6.1.5.5.7.3.4) Time Stamping (1.3.6.1.5.5.7.3.8) Unknown Key Usage (1.3.6.1.4.1.311.2.1.21) Unknown Key Usage (1.3.6.1.4.1.311.2.1.22) Microsoft Trust List Signing (1.3.6.1.4.1.311.10.3.1) Unknown Key Usage (1.3.6.1.4.1.311.10.3.3) Encrypting File System (1.3.6.1.4.1.311.10.3.4) Unknown Key Usage (2.16.840.1.113730.4.1) File Recovery (1.3.6.1.4.1.311.10.3.4.1) IP security end system (1.3.6.1.5.5.7.3.5) IP security tunnel termination (1.3.6.1.5.5.7.3.6) IP security user (1.3.6.1.5.5.7.3.7) IP security IKE intermediate (1.3.6.1.5.5.8.2.2) Smart Card Logon (1.3.6.1.4.1.311.20.2.2) OCSP Signing (1.3.6.1.5.5.7.3.9) Unknown Key Usage (1.3.6.1.5.5.7.3.13) Unknown Key Usage (1.3.6.1.5.5.7.3.14) KDC Authentication (1.3.6.1.5.2.3.5)