Not only that, It changed the entire Github experience without any active interaction. In other words we can safely assume that unchecked/untested changes are rolled out to all users.
Looks like...

and users can not reach the submenus to turn those changes off or to even properly give feedback.. I can't even reach my own profile settings..

I am 100% sure the version will not help but here it is macOS10.15 Safari
It was still working just round about 3 months ago (the missing background issue came up), and since yesterday the "colorblind" theme took everything over.

those huge impacts of a change are likely impossible to stem from a browser version..
see 5 days ago it looked like...

now it looks like..

here proof extensions are turned off, browser reloaded..

Here .AppHeader 3 days ago..

and now..

We can see that var() statements are not valid. Meaning the inspector shows no = symbol in front of those css rules. The properties got lost, are not set or ended up in another hierarchy unresponsible.
I can even see a potential typo.. "var(--AppHeader-bg)" vs "var(--appheader-bg)" and a paradigm problem by "--color-border-default" vs "--borderColor-default".

Just for the sake of proof. There is a more serious css rule naming issue because i can fix all of the entire css with a simple injection via dev-extension that simply overrides all those fancy rules with local one on :root and takes care of name doublets. Which results in such visual where the backgrounds are fixed but the menu drop downs are not fixed.

breaks it down to at least those messed up rules either missing or wrongly assumed to exist.

:root {
--bgColor-inset: #f6f8fa;
--fgColor-default: #1f2328;
--borderWidth-thin: 1px;
--borderWidth-thin-modernoterror: max(1px, 0.062rem);
--borderColor-default: #d0d7de;
--borderColor-accent-muted: rgba(84,174,255,0.4);
}
.Overlay {
    z-index: 1000; //fixes the menu trash
}

In other words, i can even turn it on or off.

You can hire me. Lol! Not lol.. who knows..

I am not telling versions cause it is security concern, at least not over this threat.. and i will do anything to avoid the classic shrug off comment i shall update then, cause that changes the paradigm to use a website around to blame users.

Reasons for such bugs to appear here is likely introduced by throwing out 20+ years industries practise in favour of convenience (could have used the word lazy, same same) coding and with it ignoring W3C standards. That is in particular the case with react based frameworks, we are practically in a new browser "war" just this time the backend coders take over API of third parties without thinking what impact that will have on their user base that has not the same goals as those who introduced those changes. In other words your product suffers a third party introduced problem since a while. You might have to ask yourself why the product team is ok with that much leaverage over your code by a third party.

Just 3 examples out of the box of the most made totally avoidable mistakes:

• javascript: catch last entry. arrayobject[length-1] most often unchecked replaced by obj.at(-1)
  If polyfill would work for such all would be fine, but for that polyfill needs to be loaded really before the first application of such function, yet react in example uses the at(index) function before polyfill can even do anything about it. Means the simple use of at() already breaks your whole code base even if you offer polyfill.

• javascript: another major bug stemming from react coding practises or like-like "clever" javascripters. That is the attempt of using hidden function names by violating W3C specs on purpose.
  What? You read that correctly. It is possible to hide an object by using "-" in its key, aka function or object name. When such object names are passed around as string it will work, as soon you forgot that it must be a string in every use you might call stringprefix - stringsuffix which is a mathematical expression and not a string as key. Seen quite often, means an object will not be found, ergo all subsequent functions can not be called nor guaranteed to be called. On top it might work in your environment, but in environments that take security concerns serious it will fail, it abuses the js language, well until it breaks apart. I bet you can even lower dev and support costs by simply using "_" instead of "-". And "-" doesnt make a site more secure because it solely marks objects as those who are to be hijacked cause someone hide them on purpose, total useless coding style, an attacker would simply use the string and still have access, and the console even tells what name it must be, which is worse!

• javascript: also classic, using "#propertyname" for properties in classes to mark them private, but in browsers that took security serious such property can never be accessed outside the class, yet still many "export" rules are used forgetting that such property is private and therefore the subsequent code becomes invalid, the private property can't be accessed anywhere, the name says it with "#" in front. Also a bug you might not detect in modern browsers, which tells even a weakness - because i can access private properties while i never should be able to.

I presented a clear debug strategy with my screenshots and code snippets.
You might want to make sure your (https://caniuse.com/?search=--) use of --var is loaded into :root css rules and also triggered. No trigger, no application of those rules. You might even have to deliver them as default via css and then later trigger their application by writing them again. That means the browser versions nore extensions do interfere, it is solely the case that github loads --var where they do not belong, to late in the buildup or have name-scheme problems. Any typo makes them simply not work apart from the "!important;" rule that changes their behaviour quite a lot.

And i feel actually ashamed i had to write this all.