It could be a fine solution. You don't want to spend infinite time designing and implementing your game, so at some point you have to put the pencil down.
For my case this is a good solution.
Peripheral code, like a menu system, doesn't deserve the same amount time and attention to the core, which you'll be iterating on more and where poor design will slow you down more and more over time.
This is the crux of design, can you come up with a way of decoupling this data that you currently feel you need to "send around"?
Separating into another class will create extra complexity with interfacing and continously sending data around from one class to another.
I'd have to see some code to understand exactly what is going on, but it isn't immediately obvious to me why the menu and application need to interact so heavily. If you were to show us the header file, and outline which functions would be implemented in the different source files, we would really start to see your design.
For very simple games, a simple menu enumeration can suffice. There is nothing wrong with a few switch statements to call your main menu rendering logic, your audio settings rendering logic and having another switch in your menu event loop dispatcher - it gets the job done.
For games with a bit more going on, I've also used a simple "game state" model, the application delegates to the current state, e.g. update, render, handle input. The current state can return a new state at the end of each loop. The state could be an PlayIntroState, a MainMenuState, various other menu states, a LevelLoadingState and a PlayLevelState. With such a design, you might end up with a lot more classes / files, but each one is very simple and does just one thing. The application can be largely ignorant of the actual details of the states it is cycling through, once it has the initial state.
For complex games (which I don't write), I imagine you'll probably be configuring / scripting / skinning whatever menu systems the game engine provides you.