Proving two public keys are derived from the same seed, without revealing the xpub and the path? Let's think about the following scenario:

Key0 is derived from SEED at path m/44'/0'/0'/0/0
Key1 is derived from SEED at path m/44'/0'/0'/0/1

I am wondering if there's a way to prove that Key0 and Key1 share the same seed WITHOUT having to share the SEED or any Xpub along the way.
Basically I want to be able to prove two keys are somehow related without risking security (Where if you share an Xpub and one of its child private keys gets leaked, the entire sibling set is compromised).
It doesn't have to be exactly this, but my goal is to prove that two keys are related without sacrificing security, so if there are ways to do this, I would appreciate those solutions too.
This is possible with zero-knowledge proofs but not with the math used in BIP32 alone.
This is because Key0 and Key1 are not related to each other mathematically except that they were derived from the same parent key, using the same chain code (an extra 32 bytes of entropy described in BIP32). Therefore to prove they are derived from the same parent public key you must reveal that parent public key and the chain code -- and these are the two most important values contained in an xpub (there is some metadata as well).
Note that you do not have to reveal the MASTER public key of the seed, just the parent key which in your example is at path m/44'/0'/0'/0.
For details, read how child public keys are derived from their parent public key in BIP32.
(summarized):
let I = HASH512(&lt;chain code&gt; || &lt;parent public key&gt; || &lt;index&gt;).
let J = the first 256 bits of I
child public key = &lt;J&gt; * &lt;G (generator point of curve)&gt; + &lt;parent public key&gt;

So the only relationship between Key0 and Key1 is that they were both derived this way, where &lt;index&gt; = 0 and &lt;index&gt; = 1.
Vitalik Buterin wrote a great article for Bitcoin Magazine in 2013 about this problem. If you reveal an extended parent public key (which includes the chain code) and any (unhardened) child private key, the parent private key can be computed. This is because the data needed to derive a child private key from a parent private key is available to the attacker (in the parent xpub). So the attacker can just subtract that value from the child private key to compute the parent private key.
As a final note, don't forget that if you need to prove that you control two keys, you can just sign the same message with each key :-)