He refuses to listen to the team, and he recently stopped code reviews, unit testing, sharing the implementation details...
Code reviews don't necessarily require the coder to submit the work for review.
An easy way to keep track of what he does is to keep an eye on the VCS history, looking for his check-ins. If you're worried about his code, this is an easy way to find it. Get a diff history, look at what he put in, and see if any red flags jump out at you. Catch his checkins fast enough and if you find a problem, you can roll back the commit and e-mail him to that effect. You are allowed to call out your fellow team members, even as a junior coder, when you see something obviously wrong.
Yes, he "codes" fast, but his code is just a bug generator. Other team members and I are in a "bug fixing phase" and 80% of bugs comes from his code. I don't want to fix his bugs. And management is blind, or doesn't want to see this, or maybe they like his "speed".
Code comes from requirements. Requirements result in runnable tests that verify the requirements have been met. Those tests can be further broken down, and can be written before changes are made to verify that the changes meet the requirements (red-green-refactor; the essence of TDD).
Add a "code coverage" metric to your team's build server (hopefully you have one; if not, that's your first problem). Simply checking that unit tests pass won't catch the problems with his new non-TDDed code, made in areas that don't have unit tests. After running all unit tests, the build server should ideally have executed every line of code, but there really are some things you just can't unit-test. Realistically, you should still be able to expect 95% coverage or better (or exclude certain libraries or types of files from coverage). Sooner or later, your cowboy will check in something that breaks the build because he's dropped the coverage level below the threshold, and you call him out.
And as far as "speed" is concerned, speed is how fast you get things "done", and it's not "done" until it's done correctly. You can put it to your managers this way; consider an auto mechanic who, when the manager takes his BMW to get an oil change, forgets to out the oil pan plug back in, and as a result all the new oil pours out before he even drives out of the garage. Sure, the oil change only took five minutes, but the manager's not going to care about that when his car's engine seizes up on the way home. He's going to care that the mechanic missed a step, that is going to cost him a lot of additional time and money to have fixed. Right now, he's paying one cowboy to do the job really fast, and then he's paying the rest of the team a much larger sum to come in and re-do the job correctly. What, really, is the advantage of continuing to let the cowboy do his thing?
Is there any way that I (as his younger colleague by age, not his boss) can do something about it?
Call him out. When you find something he screwed up, show him how his code is failing, how he could have prevented the problem in the first place (including proper design, TDD, code reviews) and what you were or will be required to do as a result to fix his broken code.
I feel like I'm the last one who really cares about the project at all.
klaxons blaring, lights flashing, sirens wailing - if you really do feel like you're the only person who cares about the quality of code produced by the team, then there is a SERIOUS problem. If you feel you're trying to drag the entire team kicking and screaming into the era of good coding, and it's just too much weight to haul, then drop it. If there's another team at the company that's doing it right, ask for a transfer, otherwise get the hell out.